> http://manticore.cs.uchicago.edu/papers/pldi20-stacks-n-conts.pdf http://manticore.cs.uchicago.edu/papers/pldi20-stacks-n-cont... Odd they didn't compare the

> http://manticore.cs.uchicago.edu/papers/pldi20-stacks-n-conts.pdf http://manticore.cs.uchicago.edu/papers/pldi20-stacks-n-cont... Odd they didn't compare the most common strategy used in practice, which is the one the linux kernel uses. The technique is described in mmap(2), under the MAP_GROWSDOWN flag. Even if you allow for a 64Kb stack for each green thread a 32bit machine has enough virtual address space for thousands of stacks. If you need more add an option to trim down the stack size. > But again, that's purely for the blocking semantics, it isn't about calling into C vs calling into Rust. Yes, it's blocking semantics. But the reason given for abandoning green threads was those calls from Rust to C were too slow in green threads, and the only reason I can see that would be is the library is attempting to hide those blocking semantics by intercepting every C call. It it didn't there would be no speed disadvantage. Yes, intercepting slows down the call by an order of magnitude. But there is another solution - don't intercept the calls, let the programmer handle it instead. That's the solution async adopts. If you are going to claim green threads are slower than async then it's only fair to compare apples with apples, and that means comparing implementations that do it the same way. Mind you, it's purely a guess on my part that the old green threads implementation slowed C calls by intercepting them, so it's purely a guess we aren't comparing apples with apples. The guess is based on the fact there is no other reason green threads C calls should be slower, as C doesn't care one way or the other. > There are other great reasons to choose that model, but for Rust's systems language goals, as well as its performance goals I can't see what systems language goals would be broken by green threads - but then I'm not familiar with them. Apart from the C call thing, green threads should be faster as they are storing data on the stack rather than copying it into a manually allocated block. Since the C call thing is looks to be a problem with the design choices of that early Rust green thread model, I don't trust the claim an implementation of green threads that makes the same tradeoffs as async currently does would be slower. And green threads does provide a much cleaner API. But I guess the response to my whinging at this point is "patches are welcome", or rather an appropriate green thread implementation.