[issue6721] Locks in python standard library should be sanitized on fork
Steffen Daode Nurpmeso
report at bugs.python.org
Sun May 15 19:03:50 CEST 2011
Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:
@ Charles-François Natali wrote (2011-05-15 01:14+0200):
> So if we really wanted to be safe, the only solution would be to
> forbid fork() in a multi-threaded program.
> Since it's not really a reasonable option
But now - why this? The only really acceptable thing if you have
control about what you are doing is the following:
class SMP::Process
/*!
* \brief Daemonize process.
*[.]
* \note
* The implementation of this function is not trivial.
* To avoid portability no-goes and other such problems,
* you may \e not call this function after you have initialized
* Thread::enableSMP(),
* nor may there (have) be(en) Child objects,
* nor may you have used an EventLoop!
* I.e., the process has to be a single threaded, "synchronous" one.
* [.]
*/
pub static si32 daemonize(ui32 _daemon_flags=df_default);
namespace SMP::POSIX
/*!
* \brief \fn fork(2).
*[.]
* Be aware that this passes by all \SMP and Child related code,
* i.e., this simply \e is the system-call.
* Signal::resetAllSignalStates() and Child::killAll() are thus if
* particular interest; thread handling is still entirely up to you.
*/
pub static sir fork(void);
Which kind of programs cannot be written with this restriction?
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________
More information about the Python-bugs-list
mailing list