[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Child process start-up errors [was: svn commit: r16891 - trunk/subversion/libsvn_subr]

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-10-23 21:25:19 CEST

On Sun, 23 Oct 2005, Julian Foad wrote:

> Peter N. Lundblad wrote:
> > On Sun, 23 Oct 2005, Philip Martin wrote:
> >
> >>Ah yes, you are right. Hmm, what happens if errfile is null and
> >>stderr has been closed, I think the fprintf is undefined behaviour?
> >
> > Now, *that's* a real problem! I'll use APR files instead.
>
> It seems to me that if svn_io_start_cmd fails to start the command, it
> would be better to return an svn_error_t rather than a message on
> stderr.
>
That would indeed be the most ellegant and consistent solution. But, as I
pointed out previously, failure to execute a program canstill be reported
on stderr, say by the dynamic linker or a shell. So, a caller already has
to take care of that.

> This seems like a design flaw in APR: different interfaces on different
> platforms. So, the most consistent thing to do would be to make the
> errors on "fork" platforms end up being reported the same way as on
> non-"fork" platforms, by a simple status code. This should be done in
> APR, and this "errfn_set" function should be removed. However, let's
> see if the approach is feasible and desirable first.
>
I don't know if the APR people took this route because it was simple (for
them), or they found it hard to find a portable solution.

> If my approach makes sense, and we implement it in Subversion rather
> than APR, the only remaining difficulty is getting the error information
> back from the static callback function to our "svn_io_start_cmd". This
> is done by associating user data with the pool, as described here:
>
> > /**
> > * The prototype for APR child errfn functions. (See the description
> > * of apr_procattr_child_errfn_set() for more information.)
> > * It is passed the following parameters:
> > * @param pool Pool associated with the apr_proc_t. If your child
> > * error function needs user data, associate it with this
> > * pool.
> > * @param err APR error code describing the error
> > * @param description Text description of type of processing which failed
> > */
> > typedef void (apr_child_errfn_t)(apr_pool_t *proc, apr_status_t err,
> > const char *description);
>
You'd have to use some kind of IPC for this, say a pipe as ghudson
suggested. But I don't see how the pool userdata should work. What if one
pool is used for more than one comman?

To be honest, I feel a solution like this is too complex for this kind of
problem. And since the child process can output to stderr anyway, it
wouldn't buy us that much in practice.

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 23 21:26:33 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.