Peter Amstutz says:
> 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.
It's probably just that the documentation is a little out of date. GHC used
to do this, but since 4.00 we haven't had the threadWait primitives.
> 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!)
Anything we might be able to help out with?
> 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.
Well, now that we have a customer for this stuff it'll get pushed up the
priority list!
[snip]
> 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.
This is a possibility, but it would involve checking for the alarm return
around every system call and performing a yield, which I guess is about as
much work as implementing the threadWait stuff. Plus it doesn't leave the
alarm signal free for Haskell programs to use, and we already make use of
the virtual timer for profiling.
> 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 :)
unfortunately we can't map Haskell threads onto POSIX threads for a couple
of reasons (and probably more):
- Haskell threads share the same heap, so you need some kind of
locking.
- Haskell threads are very light-weight, it's entirely reasonable
to have tens of thousands of them in your program. POSIX threads
are a lot heavier than we need.
These problems can be mostly solved, and in fact I plan to have a go at this
sometime. The idea is to use a small number of OS threads mapped onto
running Haskell threads (probably one OS thread per processor in your
machine). Each OS thread has its own private heap for allocation, so
locking only needs to be done on the shared portion of the heap and only
when entering a new thunk or updating a mutable object. The RTS still has
to be largely single-threaded, so you have to stop all running threads in
order to do a garbage collection for example (unless you want to get into
multi-threaded GC...).
This way you get explicit parallelism on a multi-processor, and hopefully
the locking overhead won't be too bad. But this is all a long way off.
Cheers,
Simon
