More Finaliser Trouble

[Alastair Reid]

> 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