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. An inherited scheduler will carry over state into the child process, and depending on the underlying event loop mechanism (e.g. epoll, kqueue, io_uring) may not work at all in the child process. The child process also "inherits" the blocking mode of the fiber from which the fork made, so if a fork was made from a non-blocking fiber, the main fiber of the forked process will stay in non-blocking mode, which may lead to unexpected behavior. By default, In a fresh Ruby process, each thread's main fiber is always blocking. The proposed solution: solution - Remove the fiber scheduler from the main thread after a fork. - Reset the main fiber to blocking mode after a fork. The associated PR: https://github.com/ruby/ruby/pull/15385