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