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 sdaoden
Recipients bobbyi, gregory.p.smith, neologix, nirai, pitrou, sdaoden, vstinner
Date 2011-05-15.17:03:49
SpamBayes Score 4.50423e-12
Marked as misclassified No
Message-id <20110515170342.GB21350@sherwood.local>
In-reply-to <>
@ 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?
Date User Action Args
2011-05-15 17:03:50sdaodensetrecipients: + sdaoden, gregory.p.smith, pitrou, vstinner, nirai, bobbyi, neologix
2011-05-15 17:03:50sdaodenlinkissue6721 messages
2011-05-15 17:03:49sdaodencreate