Don't setenv in multi-threaded code on glibc

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.

[ Parent | on HN ]

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".)

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by loeg on Wednesday February 01, 2017 @08:18PM (#13547206)

I'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.

[ Parent | on HN ]