[dboreham]

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]

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]

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]

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/... says Solaris 9 was the transition point).

[pjmlp]

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

[marwis]

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]

Oh, actually one can just spawn non-virtual thread to solve it.

[nerdponx]

It works well enough in Python and NodeJS.

[kaba0]

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