On 1/17/06, Peter N. Lundblad <peter@famlundblad.se> wrote:
> The attached patch fixes the problem by explicitly making the pipe
> descriptors non-inherited, avoiding the leaked descriptors. It still means
> that a hook that puts some job in the background has to redirect stderr,
> but it already had to to be safe. I think it is reasonable to have the
> script author explicitly discard the stderr output.
>
> Alternatives:
> One alternative to this would be to have a temp file instead of a pipe.
> Then just wait for the hook script and then read the temp file and delete
> it. This avoids blocking even if the hook script doesn't redirect the
> background process' stderr, but this will still have the grandchildren
> holding the tempfile open and we know how problematic it can be to delete
> an open file on Windows...
>
> On IRC, it was suggested to check if the child process is still alive and
> do non-blocking reads in some loop. This is complex and doesn't really
> work, since we don't know when to stop reading, actually.
>
> Any objections to commit this patch and propose it for 1.3 backport?
This seems reasonable to me, but I still wish there was a way to
return to the situation where hook scripts that exit success don't
have to worry about this sort of thing. I imagine there are a number
of scripts out there with this sort of problem, even our examples
don't bother to close stderr, if we're going to require that we should
at least fix the default templates.
In any event, if we do go with this fix I think we should include some
documentation on the correct way to correctly close stderr for various
systems. Your example here covers unix shell scripts, but I'd
specifically like to include something for windows batch files (not
that I have any clue how to do that in a batch file, but I suspect
people will ask for it).
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 17 21:52:30 2006