On Sun, 25 Jul 1999, Simon Marlow wrote:

> The problem here is that the Concurrent Haskell implementation in ghc-4.02
> can't preempt a thread that's blocked on I/O.  We're working on a temporary
> fix using the threadWait{Read,Write} primitives from pre-4.00 versions of
> GHC (right, Sigbjorn? :-).  The real fix will probably involve using OS
> threads on systems that support them, and this is something we definitely
> want to support.

Hmmm, from the documentation it suggested that the ghc system wouldn't
block on _ghc_ IO operations, only if you went out to say a C routine and
did a blocking call there.  Guess I was wrong.  I noticed that
threadWaitRead wasn't implemented in the cvs source for 4.03 I have lying
around (well, I could never compile it but at least having the source is
good for something!)

Well, that's annoying. I was hoping to write a multithreaded server where
each thread would service a connection with a few central controlling
threads running the whole show.  Guess I can't if any blocking anywhere
brings everything to a screeching halt.

Any idea of a timeline?  Otherwise I'm going to have to keep stumbling
around in C++ for this project.  I got into a big argument with a couple
friends about re-writing it in Haskell (because it would vastly simplify
debugging, especially with concurrent threads because functional programs
tend to be much more deterministic) and I would love to prove them wrong,
but I can't very well do that if I can't even do the basic architecture in
Haskell... :(

Hmmm, couldn't ghc use alarm signals to trigger context switches?  Like
setitimer()/signal() in C...  If a signal occurs during a blocking call it
breaks the call with an "alarm" errno, and if you detect that you could
restart the call automatically.  Just a thought, I don't know too much
about compiler writing.

Hmm, here's a thought.  If ghc supports compiling to C, would it be
possible to support POSIX threads there?  Unlike producing assembly, you
wouldn't have to deal with context switches munging the stack and whatnot
that makes OS threads hairy, just hand it off to the C compiler :)

Anyway, thanks.

           ------------------ Peter Amstutz --------------------
           -------------- [EMAIL PROTECTED] -------------
           ------- http://www-unix.oit.umass.edu/~tetron -------
           -----------------------------------------------------

Reply via email to