Author neologix
Recipients Giovanni.Bajo, avian, bobbyi, gregory.p.smith, neologix, nirai, pitrou, sdaoden, vstinner
Date 2011-06-30.12:55:56
SpamBayes Score 5.5337e-11
Marked as misclassified No
Message-id <BANLkTin+1vDCCKjc-LkBhcG1mMQU+ypiRg@mail.gmail.com>
In-reply-to <1309428337.09.0.842472815121.issue6721@psf.upfronthosting.co.za>
Content
> The way I see it is that Charles-François' patch trades a possibility of a deadlock for a possibility of a child process running with inconsistent states due to forcibly reinitialized locks.
>

Yeah, that's why I let this stale: that's really an unsolvable problem
in the general case. Don't mix fork() and threads, that's it.

> I don't like increasing complexity with fine-grained locking either. While the general case is unsolvable what Giovanni proposed at least solves the specific case where only the basic IO code is involved after a fork. In hindsight the only real life use-case I can find that it would solve is doing an exec() right after a fork().
>

Antoine seems to think that you can't release the I/O locks around I/O
syscalls (when the GIL is released). But I'm sure that if you come up
with a working patch it'll get considered for inclusion ;-)

> Since I think we agree you can't just disable fork() when multiple threads are running, how about at least issuing a warning in that case? That would be a two-line change in threading.py.

You mean a runtime warning? That would be ugly and clumsy.
A warning is probably a good idea, but it should be added somewhere in
os.fork() and threading documentation.
History
Date User Action Args
2011-06-30 12:55:57neologixsetrecipients: + neologix, gregory.p.smith, pitrou, vstinner, nirai, bobbyi, Giovanni.Bajo, sdaoden, avian
2011-06-30 12:55:56neologixlinkissue6721 messages
2011-06-30 12:55:56neologixcreate