Bug #21717: Cleanup fiber scheduler after fork

• Status: Feedback
• Assignee: -
• Target version: -
• Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN

[noteflakes (Sharon Rosner)]

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, each thread's main fiber is always blocking.

The proposed 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

[Dan0042 (Daniel DeLorme)]

Ruby already has an API for this: Process._fork

If your Fiber scheduler needs to be reset after a fork, I would recommend hooking into this.

[noteflakes (Sharon Rosner)]

• Subject changed from Introduce Fiber::Scheduler#process_fork hook to Cleanup fiber scheduler after fork
• Description updated (diff)

[noteflakes (Sharon Rosner)]

• Tracker changed from Feature to Bug
• Description updated (diff)
• Backport set to 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN

[noteflakes (Sharon Rosner)]

• Description updated (diff)

[mame (Yusuke Endoh)]

• Status changed from Open to Feedback