homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Elad Lahav, dstufft, eric.araujo, gvanrossum, pitrou, vstinner
Date 2020年03月01日.13:57:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1583071023.03.0.715186264418.issue39763@roundup.psfhosted.org>
In-reply-to
Content
@Elad:
> I'm not convinced that a multi-threaded fork()+exec() from C would be any better, unless the Python code goes to great lengths to avoid any non-async-signal-safe operations between the fork() and the exec().
That's exactly what the C code in the C subprocess module for POSIX does, though:
https://github.com/python/cpython/blob/master/Modules/_posixsubprocess.c#L828-L854
That's why I hope that using subprocess instead of a fork()+exec() sequence naively coded in pure Python would solve the issue.
@Guido:
> I can sort of see why you consider the small example a red herring, since it mixes threads and fork
Perhaps "red herring" was the wrong expression. What I mean is that it's no surprise that fork()+exec() sequence written in pure Python would be unsafe in multi-thread settings. The solution, though, is not to avoid threads or try to workaround the issue in ThreadPoolExecutor, but rather to avoid doing fork()+exec() in pure Python.
History
Date User Action Args
2020年03月01日 13:57:03pitrousetrecipients: + pitrou, gvanrossum, vstinner, eric.araujo, dstufft, Elad Lahav
2020年03月01日 13:57:03pitrousetmessageid: <1583071023.03.0.715186264418.issue39763@roundup.psfhosted.org>
2020年03月01日 13:57:02pitroulinkissue39763 messages
2020年03月01日 13:57:02pitroucreate

AltStyle によって変換されたページ (->オリジナル) /