Re:Don't setenv in multi-threaded code on glibc
by quotemstr on Tuesday January 31, 2017 @05:26AM
(#13529307)
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.
[ Parent
| on HN ]
Re:Don't setenv in multi-threaded code on glibc
by loeg on Tuesday January 31, 2017 @12:48PM
(#13533108)
You 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.
Re:Don't setenv in multi-threaded code on glibc
by quotemstr on Tuesday January 31, 2017 @11:53PM
(#13538367)
So 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".)