3 ms·

My long held belief: green/user-level/M:N threading schemes never work at first, and only work reliably after extreme effort has been put into fixing all the ca

My long held belief: green/user-level/M:N threading schemes never work at first, and only work reliably after extreme effort has been put into fixing all the cases where blocking code gets called underneath. afaik there are only two modern working implementations: golang and erlang. This article is consistent with that belief.

cyberax 3y ago
There are many other implementations, although in less popular languages. The trick is to include the green threads from the start, so there are no libraries that depend on real threading. That's why Go and Erlang are so successful.
- kelnos 3y ago
  The funny thing is that Java did have green threads back in v1.1, but they were dropped in v1.3. That doesn't invalidate your point; more than 20 years of Java practice has focused on making things work well for platform threads.
  - andrewf 3y ago
    I think Solaris moved from green threads to pure kernel threads at the same time (https://docs.oracle.com/cd/E19253-01/816-5137/mtintro-75924/index.html https://docs.oracle.com/cd/E19253-01/816-5137/mtintro-75924/... says Solaris 9 was the transition point).
pjmlp 3y ago
Go suffers the same issue when calling into native code, that is why it has APIs to deal with it. For example, https://pkg.go.dev/runtime#LockOSThread https://pkg.go.dev/runtime#LockOSThread
- marwis 3y ago
  This seems different. It pins goroutine until it is explicitly released ensuring that multiple native calls will remain on the same platform thread and nothing else is going to use it. This is critical for namespace manipulation on Linux. Java only pins for duration of native call and synchronized blocks. It looks like Java does not offer equivalent API? For now could be achieved with synchronized but if synchronized will be changed in the future to not pin it would break.
  - marwis 3y ago
    Oh, actually one can just spawn non-virtual thread to solve it.
nerdponx 3y ago
It works well enough in Python and NodeJS.
- kaba0 3y ago
  That’s M-on-N, with N being 1. That’s basically a trivial problem in comparison.

cyberax 3y ago

There are many other implementations, although in less popular languages. The trick is to include the green threads from the start, so there are no libraries that depend on real threading. That's why Go and Erlang are so successful.

kelnos 3y ago
The funny thing is that Java did have green threads back in v1.1, but they were dropped in v1.3. That doesn't invalidate your point; more than 20 years of Java practice has focused on making things work well for platform threads.
- andrewf 3y ago
  I think Solaris moved from green threads to pure kernel threads at the same time (https://docs.oracle.com/cd/E19253-01/816-5137/mtintro-75924/index.html https://docs.oracle.com/cd/E19253-01/816-5137/mtintro-75924/... says Solaris 9 was the transition point).

pjmlp 3y ago

Go suffers the same issue when calling into native code, that is why it has APIs to deal with it. For example, https://pkg.go.dev/runtime#LockOSThread https://pkg.go.dev/runtime#LockOSThread

marwis 3y ago
This seems different. It pins goroutine until it is explicitly released ensuring that multiple native calls will remain on the same platform thread and nothing else is going to use it. This is critical for namespace manipulation on Linux. Java only pins for duration of native call and synchronized blocks. It looks like Java does not offer equivalent API? For now could be achieved with synchronized but if synchronized will be changed in the future to not pin it would break.
- marwis 3y ago
  Oh, actually one can just spawn non-virtual thread to solve it.

nerdponx 3y ago

It works well enough in Python and NodeJS.

kaba0 3y ago
That’s M-on-N, with N being 1. That’s basically a trivial problem in comparison.