S. Alexander Jacobson
alex at i2x.com
Fri Jun 25 16:19:33 EDT 2004
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
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:
> Hope that sheds some light.
Ah. Very interesting. Thank you.
S. Alexander Jacobson mailto:me at alexjacobson.com
More information about the Haskell-Cafe