On 28 March 2006 11:14, Malcolm Wallace wrote:
There are certainly technical questions. If Hugs's implementation of concurrency is not concurrency after all, on what basis do we make that determination? Why is a definition of concurrency that encompasses both ghc and Hugs models unacceptable?
Ok, I'll try to nail down what we should require in terms of fairness (which is the same as pre-emption). The Concurrent Haskell paper [1] gives two requirements. These are: No runnable process will be indefinitely delayed No thread can be blocked indefinitely on an MVar unless another thread holds the MVar indefinitely. The spec also needs to say something about non-blocking foreign calls and concurrent I/O. Both are important, because one of the main uses of concurrency is as a way of structuring a program that interacts with asynchronous external agents. So I propose for the purposes of the standard/addendum, we adopt the above definitions of fairness, together with the requirement that "safe" (and maybe "blockable") foreign calls and I/O operations do not block other threads. That would mean that Hugs doesn't currently comply. My guess is that it could be made a lot closer than it currently is - eg. the IO monad's bind could be made to 'yield' occasionally, non-blocking foreign calls could be implemented, and the I/O library could be made to use them. But this is all real work. If you want to be really picky, GHC doesn't comply either, because a thread can avoid pre-emption by not doing any allocation (we consider this a bug). Cheers, Simon [1] http://www.haskell.org/ghc/docs/papers/concurrent-haskell.ps.gz