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.)
>>> * @param pool Pool associated with the apr_proc_t. If your child
>>> * error function needs user data, associate it with this
>>> * pool.
[...]
>>>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?
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.
> 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?
> 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.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 25 14:43:45 2005