1 |
On Sunday 30 October 2005 01:04, Brian Harring wrote: |
2 |
> On Sun, Oct 30, 2005 at 12:25:23AM +0900, Jason Stubbs wrote: |
3 |
> > By the way, this method does not allow having a pipe open to a child |
4 |
> > process other than stdin, stdout or stderr. |
5 |
> |
6 |
> It does; the portage_exec that is in stable is the modified version I |
7 |
> created for ebd, which uses this exact functionality. |
8 |
> |
9 |
> line #153 of trunk/pym/ebuild.py, example call- |
10 |
> |
11 |
> self.pid = spawn_func(self.ebd+" daemonize", fd_pipes={0:0, 1:1, 2:2, |
12 |
> 3:cread, 4:dwrite}, returnpid=True,env=env, *args, **spawn_opts)[0] |
13 |
|
14 |
Yep. Oversight on my part. |
15 |
|
16 |
> > > The original code is ugly, and knowing a bit more this time around I'd |
17 |
> > > write it a bit differently, that said the protections/behaviour |
18 |
> > > originally in it should be left- it's more robust, and is expected |
19 |
> > > now. |
20 |
> > |
21 |
> > I disagree here. Presently, other than the execve call, every try/except |
22 |
> > block in portage_exec.py has bugs that are hidden by the "protections". |
23 |
> |
24 |
> Original in this case was referencing the fd_pipes additions, not the |
25 |
> true original spawn func :) |
26 |
|
27 |
Even with the fd_pipes, the try/except block in there covers a bug that is hit |
28 |
every time it is entered. |
29 |
|
30 |
> Looking through the 2.4 subprocess module (which came along after the |
31 |
> mods in question), adding an option controlling the fd cleansing would |
32 |
> make sense, as long as the default option is to close the fds. |
33 |
|
34 |
Given the threading comment, I'd be agreeable to this. However, the spawn of |
35 |
tee would have to specifically close the write side of the pipe when unknown |
36 |
FDs aren't closed. Is having two extra paramaters, close_fds (a list) and |
37 |
close_all_fds (a bool), to spawn okay? |
38 |
|
39 |
-- |
40 |
Jason Stubbs |
41 |
-- |
42 |
gentoo-portage-dev@g.o mailing list |