[platz]

he added an additional requirement "to tune how application runs without needing to modify the code."

So I assume that means not using things like forkio/goroutines etc.. You still have to tell haskell "fork a green thread here" instead of what he wants, which is it to be completely transparent.

Additionally, I think one can make the case the haskell green threads aren't very different from async await, in which "awaiting" is just creating some data that a scheduler maps onto a threadpool (rather like how GHC maps it's 'green threads' onto it's 'capabilities' via a scheduler)

Furthermore, if you actually want to pass data round in Haskell rather than just fork threads, it leaves it completely up to the user to figure out how to do that.. MVar's are canonical but noisy syntatically. the 'async' package is very nice, but gives the gives the same syntax OP is complaining about!

[balfirevic]

The transparency I'm after is that majority of your code can be oblivious to whether it's running in OS or green thread.

So, for example, you could configure your web server to use use green threads to handle incoming http requests but configure other part of the system to run with real threads (for whatever reason).

In the end, internally, it will of course end up similar to async/await - you need to capture the execution state and resume it which is what async/await does. I just want to be able to do it without rewriting majority of my code.

[jameshart]

In a managed platform like .NET or Java there's no reason in principle why any code should be able to tell whether it's in an OS or a green thread - the decision of how to actually accomplish having multiple simultaneously active callstacks with pre-emptive scheduling is made by the runtime. Early versions of Java used green threads within the JVM rather than relying on native threads, presumably as part of an attempt to provide consistent write-once-run-anywhere behaviors, so this is not just theoretical.

I think the async/await model arrives as a reasonable compromise in terms of supporting an alternative to OS threads in that it allows you to get the benefits of green threads (i.e. that you can process a lot of different stack contexts simultaneously without needing to spin up a huge amount of OS threads) without getting into the messy situation of having a user-space scheduler pre-emptively switching green-thread stacks (which probably needs the scheduler itself to run on another OS thread and definitely needs to be done at a 'runtime' level) - instead, you just rely on co-operative scheduling, which can be done at a 'library' level.

[platz]

> configure your web server to use use green threads to handle incoming http requests but configure other part of the system to run with real threads

this just seems like an odd feature imho, but sure i think i understand you better now.

[jameshart]

I can't imagine the fun you could get into in such a system where there are both green thread and OS thread locking primitives available...