
That's exactly what's there now, and it doesn't produce interleaving. Hugs doesn't have a global thread pool -- each instance of unsafePerformIO has its own. Once the side computation starts, it runs to completion before returning to the main thread. Even if it yields, only threads spawned inside the unsafePerformIO can take over. A global thread pool doesn't seem feasible with the current implementation of concurrency in Hugs. Concurrency is implemented in the libraries; a blocked thread is a continuation, and it's not clear how to construct that continuation in a pure context.
I'm sure you're right, but I don't understand why an unsafePerformIO has to have its own thread at all. It's fine for an unsafePerformIO to run to completion before anything else happens - in fact that's exactly what I'd expect in a single-threaded system. Cheers, Simon

On Mon, Aug 11, 2003 at 12:15:57PM +0100, Simon Marlow wrote:
I'm sure you're right, but I don't understand why an unsafePerformIO has to have its own thread at all.
In Hugs, threads exist only in the IO monad.
It's fine for an unsafePerformIO to run to completion before anything else happens - in fact that's exactly what I'd expect in a single-threaded system.
Sure, but is that what you'd expect of unsafeInterleaveIO?
participants (2)
-
Ross Paterson
-
Simon Marlow