Oh, great point! That does seem really hard, maybe even intractable. That's definitely a reason to like cooperative concurrency, huh...

Just to tangent even further, but some ideas:

- Do it the ugly way: add an artificial layer of promises in an otherwise pre-emptive, direct-style language. That's just, unfortunately, quite ugly...

- Use a lazy language. Then everything's a promise! Some Haskell optimizations feel kind of like promise pipelining. But I don't really like laziness...

- Use iterator APIs; that's a slightly less artificial way to add layers of promises on top of things, but still weird...

- Punt to the language: build an RPC protocol into the language, and promise pipelining as a guaranteed optimization. Pretty inflexible, and E already tried this...

- Something with choreographic programming and modal-types-for-mobile-code? Such languages explicitly track the "location" of values, and that might be the most natural way to represent ocap promises: a promise is a remote value at some specific location. Unfortunately these languages are all still research projects...

You're going to be surprised when you learn that futexes are an abstraction too, ultimately relying on this thing called "cache coherence".

And you'll be really surprised when you learn how cache coherence is implemented.

Colloquially, "library" and "service" have 95% of the correct connotations.

The only way to get the lesser benefit of therapy is to precommit to not report suicidal thoughts.

The greater benefit of "pilots honestly report their suicidal thoughts and then they are stopped from flying" is simply impossible to achieve, and if you foolishly try to get it anyway then you won't even get the lesser benefit.

You've implemented something which kills all your child processes when you exit cleanly, but which leaks child processes if you exit uncleanly. This is, frankly, easy to do, and not interesting. It's not a "problem".

The article is solving the problem of: how do I make sure my child processes die even if I exit uncleanly? That's an actual hard problem to solve.

In other words, core utilization is less relevant today - what you care about is energy utilization (which is shared across cores).

Of course, there's a point at which this stops being relevant - if you have multiple sockets for example, this won't apply. But work stealing across multiple sockets is so expensive anyway that you would never want to do it. You might as well work-steal across machines at that point - something which is indeed useful sometimes, but usually niche.