Home Original page

[Python-ideas] solving multi-core Python

random832 at fastmail.us random832 at fastmail.us
Tue Jun 23 07:56:50 CEST 2015 
On Sun, Jun 21, 2015, at 18:41, Antoine Pitrou wrote:
> It's actually already the case in POSIX that most things are illegal
> between fork() and exec(). However, to make fork() practical, many
> libraries or frameworks tend to ignore those problems deliberately.

I'm not _entirely_ sure that this applies to single-threaded programs,
or even to multi-threaded programs that don't use constructs that will
cause problems.

The text is: "A process shall be created with a single thread. If a
multi-threaded process calls fork(), the new process shall contain a
replica of the calling thread and its entire address space, possibly
including the states of mutexes and other resources. Consequently, to
avoid errors, the child process may only execute async-signal-safe
operations until such time as one of the exec functions is called. Fork
handlers may be established by means of the pthread_atfork() function in
order to maintain application invariants across fork() calls."

Note that it uses "may only" (which is ambiguous) rather than "shall
only". It could be read that "only [stuff] until exec" is a suggestion
of what the child process "may" do, under the circumstances described,
to avoid the particular problems being discussed, rather than as a
general prohibition.

And the next paragraph is "When the application calls fork() from a
signal handler and any of the fork handlers registered by
pthread_atfork() calls a function that is not async-signal-safe, the
behavior is undefined." suggesting that the behavior is _not_ likewise
undefined when it was not called from a signal handler.

Now, *vfork* is a ridiculous can of worms, which is why nobody uses it
anymore, and certainly not within Python.
More information about the Python-ideas mailing list