Concurrency

[John Meacham]

On Fri, Mar 31, 2006 at 03:59:41PM -0600, John Goerzen wrote:
> On Fri, Mar 31, 2006 at 01:51:14PM -0800, John Meacham wrote:
> > > If so, we should specify what exception is raised if, say, forkIO is
> > > called on such a system.  We should also make it clear that
> > > single-threaded implementations are required of things such as MVars.
> > > Finally, we should add a function that indicates the level of threading
> > > support on the running system.
> > 
> > routines that are guarenteed to fail becaues they arn't supported should
> > not exist, haskell tries hard to catch so many errors at compile time,
> > it would seem odd to delegate the error of missing a whole subsystem to
> > run-time :) 
> 
> Not really.  What if I'm writing a program that can take advantage of
> threading if it's available, but can degrade gracefully if not?  Should
> I be forced to use something like cpphs to detect the presence of
> threading in advance?  It would be better to detect this at runtime than
> fail to compile at all on a system that doesn't support threading, IMHO.

Yeah, actually. cpphs (or something in cabal) seems like just the right
way to go. because it is set at compile time. you don't make run-time
decisions as to whether to use unboxed arrays, control.arrow or any
other library. it would seem very odd to do so for concurrency.

Concurrency might be hidden deep in a library, you don't want to
suddenly get an unexpected "concurrency not supported" error because you
happened to use a library you didn't write in a new way. better to be
safe and catch those known errors at compile-time.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈