[Twisted-Python] epoll keep sharing state between process even after fork.

[Flint]

>
> 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).
>
> 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.
>
> 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.
>
> And that's just one of the simplest possible examples of how things can go
> wrong.
>
> 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.
>
> 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.
>
> Hope this helps,
> Jean-Paul


Thankx a lot.

I'll probably rethink everything in my project hehe, but i'm glad I asked !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-python/attachments/20131024/5b16fe65/attachment.html>