Nir Aides <n...@winpdb.org> added the comment: Steffen, can you explain in layman's terms?
On Sun, May 15, 2011 at 8:03 PM, Steffen Daode Nurpmeso <rep...@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? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6721> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
