On Fri, 25 Jun 2004, Simon Marlow wrote:
There's no fundamental difficulty that I'm aware of. The lack of these functions is probably down to historical reasons: tryTakeMVar and tryPutMVar are recent additions to the old MVar interface.
Ok. Then will take a look in the library and try to understand the concrete implementations.
It seems to me that with MVars you can implement pretty much any abstraction you need, including choice, and it's not clear that there would be any advantage to providing any more primitives. That's based on my experience so far, anyway - I know there are people out there that have made rather more heavy use of MVars than I have (eg. George Russell).
Well we appear to be having a problem implementing a takeEitherMVar or readEitherChan without adding a new abstraction....
Also, you wouldn't need these functions if Haskell's concurency model was defined to be non-preemptive. How come forkIO was not specifically defined to be non-preemptive (with forkOS dependent on the local OS native threading model)?
So threads forked by forkIO would be non-preemptive with respect to what? Other threads forked by forkIO, or forkOS?
All forkIO'ed threads would run in the same OS thread and only lose control when they block. I now realize that this model is incompatible with distributing execution onto multiple CPUs so I am wrong here? Though, in practice, does GHC actually does take advantage of multiple CPUs when they are available? Or do need GPH?
forkOS is a very recent addition, BTW. Its primary purpose is to make a "bound" thread, to give the programmer a handle on which OS thread is used to make foreign calls. See this paper we submitted to the Haskell Workshop this year:
http://www.haskell.org/~simonmar/papers/conc-ffi.ps.gz Hope that sheds some light.
Ah. Very interesting. Thank you. -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com