On Mon, 26 Jul 1999, Simon Marlow wrote:
> 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.
Is there a particular reason that this feature, once implemented, now
isn't? Some major reimplemenation or something between versions?
> > 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?
Actually I think it I finally determined that I just don't have quite the
hardware to easily compile a few key files in a resonable amount of time
(the parser output of happy is the main culprit). Anyway it looks like
what I thought I needed 4.03 for I don't really, so I'll stick with
'stable' 4.02 for now.
> > 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!
ooh, I feel important now :) Basically I'm trying to find a typesafe
functional language implementation with useful threading and can easily
talk to the outside world. ghc talks to the outside world, but the
threading isn't quite there yet... I'm afraid I'm going to look at ocaml
next ;-P
> > 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
So how do you deal with threads blocking on a syscall? This is all
handled by the kernel scheduler normally, but the only way I know of to
interrupt a syscall is with signals, unless you plan on having your
"blocking" threads just calling select() a lot...
I wouldn't mind using "heavy-weight" threading since it does get better
scheduling performance from the OS, and my application will (hopefully)
probably not service more than a couple dozen or so connections at a time,
so even with 1 thread/connection that's only 25 "heavyweight" threads or
so most of which are blocking at any given time anyway.
> 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...).
Well okay, multi-threaded GC'ing sounds incredibly tricky and painful :)
I see your point... Although at any given time most of the garbage would
be temporary values created for a specifc thread of execution. If you're
using a generational GC then you'd only need to bring everything to a
screeching GC-induced halt infrequently... But then, I don't all that
much about the intricacies of GC'ing, I wrote one little mark&sweep
algorithm for a crude lisp system I was writing for fun which most
certainly was not multithreaded...
Anyway, thanks' for paying attention to the whining of this one little
developer :)
------------------ Peter Amstutz --------------------
-------------- [EMAIL PROTECTED] -------------
------- http://www-unix.oit.umass.edu/~tetron -------
-----------------------------------------------------
