-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistent state across forks #630
Comments
Three other places I can think of in addition
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am increasingly unconvinced that snmalloc is safe to use in programs that call
fork
. I had originally thought that the mostly lockless design meant that we're safe, but I think there are three problems:fork
.fork
will leak.fork
will be in an inconsistent state.This is all bad.
The first problem can be solved by acquiring the lock(s?) in the prepare callback for
pthread_atfork
and then releasing it in both the parent and child callbacks.The second can be solved by putting all allocated allocators in a linked list and walking that list in the child to return them all to the pool (and probably coalescing them at that point).
I'm not sure about the third. Do we atomically pop things off free lists on the fast path? On anything that's doing read-modify-write operations on an allocator, we'd need an asymmetric barrier.
I'm not especially worried about this because any program that calls
malloc
from a multithreaded program that callsfork
and notexecve
is going to leak memory, but ideallymalloc
betweenfork
andexecve
should work (which requires fixing the first one).The text was updated successfully, but these errors were encountered: