>Are you using a framework, or developing one? No. >Who gets to choose the concurrency strategy? The person writing code? >Clients are the clients of the AP

>Are you using a framework, or developing one? No. >Who gets to choose the concurrency strategy? The person writing code? >Clients are the clients of the API I'm talking about, which is a hypothetical "lightweight thread" based API where everything just works as per original post. In that context, I am the client. Here's how it works: forkIO myFunction That's it. Very simple, scales to millions of "threads", and if compiled with -threaded, those millions of "threads" are spread over a set of OS threads so I also get parallelism. >The really cynical part of my mind is going "please tell me about this magical solution to integrating different event loops and concurrency models" and the less cynical part is open to your suggestions. The key is just in the "demanding better from languages" part. You don't have to worry about a dozen incompatible green thread libraries if it is built into the language.