<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">To expand on that just a bit, the form of sharing that you get when you fork() but you don't exec() is very difficult to use correctly (I think it's an open question whether it's *possible* to use correctly in a Python program).</span><br>
</div>
<br>
The argument here is similar to the argument against shared-everything multithreading.  While memory (and some other per-process state) is no longer shared after fork(), *some* per-process state is still shared. And all of the state that isn't shared is still a potential source of bugs since it's almost certainly the case that none of it cooperated with the fork() call - a call which happened at some arbitrary time and captured a snapshot of all the state in memory at an arbitrary point.<br>

<br>
Consider a simple implementation of a lock file, used to prevent multiple instances of a program from starting.  There are several ways fork() could break such code.  Perhaps it is partway through acquiring a lock on the lock file when the fork() occurs.  Perhaps the result is that the file ends up locked but no process thinks it is holding the lock.  Now no instances of the program are running.  Or perhaps the lock is held when fork() happens and the problem only surfaces at unlock time.  Perhaps one of the processes exits and releases the lock.  Now the program is still running but the lock isn't held.<br>

<br>
And that's just one of the simplest possible examples of how things can go wrong.<br>
<br>
The nearly uncountable different ways for failures to creep in and the resulting impracticality (if not impossibility) of being able to test that Twisted (or any Python library) actually works when fork() is used means that it's not likely Twisted will ever be declared compatible with any fork()-without-exec() usage.<br>

<br>
You can find some examples of Twisted-using applications that run multiple processes, though.  Apple CalendarServer does it by passing file descriptors to worker processes and sends them the location of a configuration file describing how they should behave.  Divmod Mantissa does it by inserting self-describing work into a SQLite3 database.  When the worker process finds one of these, it knows what code to load and run by looking at the fields in the row.  These are variations on a theme - RPC, not shared (or duplicated) memory.<br>

<br>
Hope this helps,<br>
Jean-Paul</blockquote><div><br></div><div>Thankx a lot.</div><div><br></div><div>I'll probably rethink everything in my project hehe, but i'm glad I asked !</div><div><br></div></div></div></div>