4 ms·
If your fork in a multithreaded program, you have bigger problems. You can deadlock taking any lock in the child that could possibly have been taken by some thr
by quotemstr 10y ago
If your fork in a multithreaded program, you have bigger problems. You can deadlock taking any lock in the child that could possibly have been taken by some thread at the time of fork. In practice, you can't predict all these locks, so the only sane thing you can do in a forked child of a multithreaded program is call async-signal-safe functions (as POSIX commandeth) and probably execve something.
- deleted 10y ago[deleted]
- loeg 10y agoYou could also invalidate all locks from the parent with some kind of generational scheme based on pid or whatever. I believe the Python interpreters do something crazy like this to try and avoid deadlock after forking multithreaded programs.
- quotemstr 10y agoSo what? Under that scheme, you can take the locks, but the lock-protected data structures are probably garbage. (That is, the locks become implicitly "abandoned", not "unlocked".)
- loeg 10y agoI'm not defending it as a model. I think python's approach to fork & thread interaction, which is to punt on it completely while exposing both to end users, is pretty broken.