Not really. There are a few (mainly FDO/Poettering ware) offenders that in theory are easy to just fix and that's what I've been pushing distros to do. However..
Conversation
It's starting to look like there are *language runtimes* that expose fork to applications in their language, and don't seem aware of the restriction.
1
1
For example Ruby is shipping tests that are almost surely invalid (UB) but that they may believe, perhaps rightly, are asserting properties that existing Ruby programs assume.
1
2
If that's the case, the problem is not just fixing software (the language runtimes affected) but fixing third party languages' contracts with their users. And that may be effectively impossible.
1
2
Replying to
Assuming the runtime itself isn’t MT, this would require a user using both MT and fork mechanisms. Not saying this is impossible or doesn’t happen, but I would think there are few eg Ruby programs doing this, so the breaking change might not be a hard ask.
2
Replying to
One of the motivations for actually wanting this to work is allowing whether something is internally MT to be treated purely as an implementation detail the rest of program doesn't have to know about.
1
1
My preferred solution to that problem is deprecating fork and treating nontrivial use of fork as the nasty detail rest of program has to tiptoe around, but languages that chose to expose fork rejected that. 😣
1
1
So I think where the problem is really hard to assign blame/responsibility for fixing is where a program in an affected language (Ruby?) uses fork and indirectly uses a module with FFI to a C library using threads they weren't even aware of.
1
1
It's a very common issue but the race condition often has a very low chance of happening in practice, so it mostly goes unnoticed. Users will notice that applications sometimes fail to start or perform an operation but it's hard for them to figure out what could be causing that.
1
2
Yep. With malloc it's noticed quickly, and glibc makes malloc work, but only malloc. Other stuff just goes unnoticed because the races are hard to hit.
1
Even with malloc, applications often don't trigger the race condition regularly. In our experience some cases only happen 1/20 times, etc.
Android uses a fork-based spawning model by default and they had to make everything used by the app runtime work, but not beyond that.
The runtime for managed code (Java, Kotlin) is explicitly designed to support this and take full advantage of it via optimizations. Some hooks like android.googlesource.com/platform/art/+ solely exist to support this spawning model. Zygote uses this to pause making new threads, as one example.
1
Show replies