> Dnia nie 13. lipca 2003 21:20, Alastair Reid napisał: > > We dropped Haskell finalizers because neither Hugs nor NHC could > > implement them and implementing them would pretty much require them to > > implement preemptive concurrency (i.e., multiple threads each with their > > own stacks).
On Sunday 13 July 2003 11:03 pm, Marcin 'Qrczak' Kowalczyk wrote: > Not necessarily preemptive. Hugs-like concurrency would be OK. No, Hugs-like concurrency would _not_ be ok. Hugs-like concurrency allows for context switches only when executing concurrency operators (yield, takeMVar, forkIO, ...) and, in particular, can only occur while in the IO monad which allowed us to add concurrency just by changing the way the IO monad was implemented. > The point is to be able to protect mutable structures by mutexes. In particular, it is the 'thunks' used by the runtime to represent unevaluated Haskell expressions which are mutable and which have to be protected by mutexes. (In GHC, these mutexes are called 'blocking queues'. Since Hugs has only non-preemptive concurrency, it provides a degenerate form of blocking queue called a 'blackhole' which reports that your program has entered a blackhole if you try to enter a locked mutex.) Since the code that evaluates the thunks can be of any type and is not restricted to the IO monad, the way concurrency is implemented in Hugs cannot be used. Instead, we would have to change the way _every_ evaluation happens in Hugs so that we are able to block the current thread if the mutex is taken. For example, we could evaluate each Haskell thread in a separate OS thread, we could evaluate each Haskell thread is a separate user-level thread (as GHC does) or we could use some form of continuation passing implementation (as SML-NJ does). I claim that either of these 'would pretty much require [Haskell implementations] to implement preemptive concurrency'. -- Alastair Reid _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi