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
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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Oct 23 21:26:33 2005