Re: [gentoo-portage-dev] [5/7] portage_exec cleanups

[Jason Stubbs <jstubbs@gentoo.org>]

On Sunday 30 October 2005 01:04, Brian Harring wrote:
> On Sun, Oct 30, 2005 at 12:25:23AM +0900, Jason Stubbs wrote:
> > By the way, this method does not allow having a pipe open to a child
> > process other than stdin, stdout or stderr.
>
> It does; the portage_exec that is in stable is the modified version I
> created for ebd, which uses this exact functionality.
>
> line #153 of trunk/pym/ebuild.py, example call-
>
> self.pid = spawn_func(self.ebd+" daemonize", fd_pipes={0:0, 1:1, 2:2,
> 	3:cread, 4:dwrite}, returnpid=True,env=env, *args, **spawn_opts)[0]

Yep. Oversight on my part.

> > > The original code is ugly, and knowing a bit more this time around I'd
> > > write it a bit differently, that said the protections/behaviour
> > > originally in it should be left- it's more robust, and is expected
> > > now.
> >
> > I disagree here. Presently, other than the execve call, every try/except
> > block in portage_exec.py has bugs that are hidden by the "protections".
>
> Original in this case was referencing the fd_pipes additions, not the
> true original spawn func :)

Even with the fd_pipes, the try/except block in there covers a bug that is hit 
every time it is entered.

> Looking through the 2.4 subprocess module (which came along after the
> mods in question), adding an option controlling the fd cleansing would
> make sense, as long as the default option is to close the fds.

Given the threading comment, I'd be agreeable to this. However, the spawn of 
tee would have to specifically close the write side of the pipe when unknown 
FDs aren't closed. Is having two extra paramaters, close_fds (a list) and 
close_all_fds (a bool), to spawn okay?

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list