[ruby-core:104994] [Ruby master Bug#18036] Pthread fibers become invalid on fork - different from normal fibers.

Issue #18036 has been updated by ioquatix (Samuel Williams).


Thanks @matz. @ko1, on my PC, the following program segfaults. I tried it on 2.7 and 3 (head).

~~~ ruby
require 'fiber'

fiber = Fiber.new do
  while true
    puts "Hello World"
    fork
    # -- C level backtrace information -------------------------------------------
    # /home/samuel/.rubies/ruby-head/bin/ruby(rb_print_backtrace+0x11) [0x5565896dca74] ../vm_dump.c:759
    # /home/samuel/.rubies/ruby-head/bin/ruby(rb_vm_bugreport) ../vm_dump.c:1041
    # /home/samuel/.rubies/ruby-head/bin/ruby(rb_bug_for_fatal_signal+0xe8) [0x5565894d75a8] ../error.c:800
    # /home/samuel/.rubies/ruby-head/bin/ruby(sigsegv+0x49) [0x556589633479] ../signal.c:960
    # /usr/lib/libpthread.so.0(__restore_rt+0x0) [0x7f3ee8ff2870]
    # /home/samuel/.rubies/ruby-head/bin/ruby(rb_ec_tag_state+0x9) [0x556589752239] ../eval_intern.h:174
    # /home/samuel/.rubies/ruby-head/bin/ruby(rb_fiber_start) ../cont.c:2054
    # /home/samuel/.rubies/ruby-head/bin/ruby(fiber_entry+0x9) [0x556589752499] ../cont.c:717
    Fiber.yield
  end
end

fiber.resume
~~~

I'm not sure, do we expect this to work?

----------------------------------------
Bug #18036: Pthread fibers become invalid on fork - different from normal fibers.
https://bugs.ruby-lang.org/issues/18036#change-93393

* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
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:

```
Fiber.new do
  fork
end.resume
```

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.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>