On Tue, 25 Oct 2005, Julian Foad wrote:
> Peter N. Lundblad wrote:
> > On Sun, 23 Oct 2005, Julian Foad wrote:
> >
> >>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.
>
> Oh yes, I forgot about that. (FWIW, we explicitly avoid using a shell in this
> case.)
>
> If the caller is starting a program that (the caller knows) never writes on
> stderr, the caller will not check stderr. The caller might check the program's
> return code. A shell or dynamic linker failure is presumably accompanied by a
> non-zero return code. Does your patch do that? I think it should. (I think
> 127 is typically used as the return code for failure to start a program.)
>
That's taken care of by APR, i.e. exiting after the errhandler is called.
It is returning -1 (!). That hasn't changed with my commit. The only
change is that the reason for termination is available through stderr.
>
> >>>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
>
> Well, isn't shared memory (in the pool) an easier kind of IPC in this
> situation?
And a mutex, or condition variable shared among processes, which isn't
available everywhere.
>
> I tried it. I can get pool user-data in to the child process from the
> parent, but not back out again. It seems as if the child receives a
> copy of the parent's pool, so that any writes into it are not seen by
> the parent.
>
Of course it gets a copy of the pool. A fork doesn't leave any memory
shared.
> > suggested. But I don't see how the pool userdata should work. What if one
> > pool is used for more than one comman?
>
> One thread cannot start more than one command simultaneously. If commands are
> started sequentially there is no problem, because the user data is only needed
> for the brief period of starting a command. Are you thinking of multiple
> threads sharing a pool?
>
No, I'm talking of two commands started in sequence. NOte that the output
from the child is asynchronous and may well happen after svn_io_start_cmd
returns.
> > 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.
>
> Well, I don't know how complex it is. If a few lines of code can copy
> the data into pool user-data and back out of it in the parent, that
> would be simple. I couldn't make it work, and maybe it's not possible;
> if that's the case, I'm happy with the stderr-plus-exit-code solution.
OK. I'll fix the problem philip pointed out (and add a note to the
docstring). If someone comes up with a better solution that isn't too
complex and that is portable, of course I wouldn't object:-)
Thanks for the discussion,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 25 17:16:48 2005