homepage

Steffen, can you explain in layman's terms?
On Sun, May 15, 2011 at 8:03 PM, Steffen Daode Nurpmeso <report@bugs.python.org> wrote:
>
> @ 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?