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:[EMAIL PROTECTED] tel:917-770-6565 http://alexjacobson.com _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
