You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary:
folly RCU currently has a somewhat awkward restriction that there may be no RCU
readers across a fork() call, and that after fork() has been invoked, no AtFork
handlers may enter a read region *unless* they spawn a separate thread in the
AtFork handler. In the child's fork() handler, we then reset the forked child
thread's TLS read counters, and even have a ForkTest that validates that if we
were in a read region while calling fork(), that the child's state is wiped out.
The fact that we zero out the forked child thread's readers rather than
explicitly just panicking is very confusing, and does not match the advertised
behavior of the RCU subsystem. The only thing that's really valid to do in if
fork() is involved is:
1. Have a single threaded program that is not in a read region.
2. Have a single threaded program that is in a read region, and immediately
invokes exec().
These restrictions are common to most librcu implementations. For folly RCU, we
can't do anything to verify that the program was single threaded when we get to
an AtFork handler, and we also can't check that if the caller is in a read
region that they will soon exec(). What we definitely should *not* do is
instill some artificial state of clearing out the read region of the forking
thread on a fork() invocation. This change therefore just removes the folly
AtFork handling logic.
Reviewed By: paulmckrcu
Differential Revision: D35557080
fbshipit-source-id: 77e3bdaaea078c60e7f7c562228de08635f164e6
0 commit comments