From: "matz (Yukihiro Matsumoto)" Date: 2021-08-19T06:57:51+00:00 Subject: [ruby-core:104993] [Ruby master Bug#18036] Pthread fibers become invalid on fork - different from normal fibers. Issue #18036 has been updated by matz (Yukihiro Matsumoto). Using fork from within non-main fibers should be prohibited only on architectures where it is unreliable (e.g. OpenBSD). Matz. ---------------------------------------- Bug #18036: Pthread fibers become invalid on fork - different from normal fibers. https://bugs.ruby-lang.org/issues/18036#change-93392 * 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: