Bug #18036


Pthread fibers become invalid on fork - different from normal fibers.

Added by ioquatix (Samuel Williams) 4 months ago. Updated 2 months ago.

Target version:


Fork is notoriously hard to use correctly and I most cases we should be encouraging Process#spawn. However, it does have use cases for example pre-fork model of server design. So there are some valid usage at least.

We recently introduced non-native fiber based on pthread which is generally more compatible than copy coroutine w.r.t. the overall burden on the implementation. However, it has one weak point, which is that pthreads become invalid on fork, and thus fibers become invalid on fork. That means that the following program can become invalid: do

It will create two threads, the main thread and the thread for the fiber. When the child begins execution, it will be within the child pthread, but the parent pthread is no longer valid, i.e. it's gone.

I see a couple of options here (not mutually exclusive):

  • Combining Fibers and fork is invalid. Fork only works from main fiber.
  • Ignore the problem and expect users of fork to be aware that the program can potentially enter an invalid state - okay for fork-exec but not much else.
  • Terminate all non-current fibers as we do for threads, and possibly fail if the current fiber exits for some reason.

Because pthread coroutine should be very uncommon, I don't think we should sacrifice the general good qualities of the fiber semantic model for some obscure case. Maybe it would be sufficient to have a warning (not printed by default unless running on pthread coroutines), that fork within a non-main fiber can have undefined results.


Also available in: Atom PDF