4 ms·
The M:N problem in Go is that you cannot control which thread runs which code. So yes, you could wish the OS exposed different APIs, but presently you can manag
by jeremyjh 9y ago
The M:N problem in Go is that you cannot control which thread runs which code. So yes, you could wish the OS exposed different APIs, but presently you can manage this situation in languages that let you manage threads.
- jchw 9y agoThe person you're replying to has already made that clear. It's, in fact, also possible to manage the problem in Go with some finagling. But like Go, if you have multiple threads, it's difficult I've hit this exact problem with multithreading in C and setuid and just because it _can_ be managed in C doesn't make it easy or straightforward. Therefore, I mirror the sentiment that there needs to be a way to operate on a process level, even if that has some interesting consequences. (P.S.: In C, if you're using glibc, it DOES actually patch this issue up on its own using one hell of a nasty hack.)
- cyphar 9y ago> P.S.: In C, if you're using glibc, it DOES actually patch this issue up on its own using one hell of a nasty hack.) I too love reading the code for nptl(7). It's a riot. :D