Bug #21717
Updated by noteflakes (Sharon Rosner) about 1 month ago
When using a fiber scheduler and forking a process, the child process "inherits" the fiber scheduler. The child process also "inherits" For the blocking mode of the fiber from which scheduler to be usable in the fork made, so if forked process, its internal state should in most cases be reset. I propose two alternatives for a fork was made from solution: 1. Introduce a non-blocking fiber, `Fiber::Scheduler#process_fork` hook, called by the main fiber of the forked process will stay in non-blocking mode, which may lead to unexpected behavior. In Ruby runtime immediately after a fresh Ruby process, each thread's main fiber is always blocking. fork. The proposed solution associated PR: https://github.com/ruby/ruby/pull/15342 - 2. Remove the fiber scheduler from the main thread after a fork. - Reset The associated PR: https://github.com/ruby/ruby/pull/15385 This PR also sets the main fiber in the forked process to blocking mode after mode, in order to prevent unexpected behavior if forked from a fork. The associated PR: https://github.com/ruby/ruby/pull/15385 non-blocking fiber.