| 1 |
On Thu, Dec 01, 2005 at 12:03:46PM -0800, Zac Medico wrote: |
| 2 |
> >>Well, I'm running the latest svn so there could be a regression in the |
| 3 |
> >>recent changes to portage_exec.cleanup(). |
| 4 |
> > |
| 5 |
> >Does changing SIKTERM to SIGKILL fix it? |
| 6 |
> > |
| 7 |
> |
| 8 |
> No, SIGKILL doesn't seem to make a difference (not a regression then). It |
| 9 |
> seems that the atexit hooks do not execute until the sys.exit() is called |
| 10 |
> in the fetcher child process (see attached test case that reproduces the |
| 11 |
> problem). Perhaps it would be more appropriate to implement parallel-fetch |
| 12 |
> with a thread rather than a fork? |
| 13 |
Thread'ing won't fly due to the code involved. Too many globals, too |
| 14 |
many structures screwed with- this is why I used fork (yes it's a mild |
| 15 |
hack, but it's so simple ;) |
| 16 |
|
| 17 |
Either way, here's the issue, atexit registers work fine across forks, |
| 18 |
portage.cleanup is registered prior to portage_exec.cleanup, so the |
| 19 |
main portage pid sits there and waits for the kids to go away on their |
| 20 |
own, then portage_exec.cleanup tries waxing the pids. |
| 21 |
|
| 22 |
Short version... cleanup's killing code never is needed at this point. |
| 23 |
So... who's up for yanking that os.wait out of portage.portageexit? :) |
| 24 |
~harring |
Archives