> > 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?
Yes, we rewrote the whole runtime system, primitives and all, between 3.02
and 4.00. One or two things got left behind as a result.
> 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.
The good news is that Simon has bitten the bullet and had a go at the space
leak in GHC - while he didn't find all the causes he did manage to squash a
third to a half of the maximum residency on average compiles. That means we
should be able to bootstrap without thrashing on a 64M machine (possibly
smaller).
> 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...
What we had in mind was a quantity semaphore around the Haskell world - only
a small number of OS threads can be "inside" and running Haskell threads at
any one time. If a thread pops outside, say to do a syscall, it would
release its lock, allowing another thread inside. The OS threads
implementation therefore handles blocking syscalls. This works even when
the quantity is 1 - i.e. we don't have to solve the other multi-threaded
Haskell world problems just to get this behaviour.
> I wouldn't mind using "heavy-weight" threading since it does
> get better
> scheduling performance from the OS,
I don't think OS thread scheduling is faster than Haskell scheduling, quite
the opposite in fact. I'd be surprised if our context switch was any more
than 100 instructions, and it doesn't involve *any* system calls. That's
one reason for not using an alarm signal - you pay for the context switch to
the OS to set up the signal, and I've been told by a couple of people that
this can be a real killer for lightweight threading.
However, the OS scheduler is probably a lot fairer and supports things like
priorities which we don't have yet.
> 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.
Ok, so for your app the I/O context switching is pretty important. Wouldn't
it be nice to be able to ramp this up to 10,000 simultaneous connections
without any visible slowdown, though? :) Try doing that with Unix threads.
Come to think of it, try doing it on Unix at all without any file descriptor
multiplexing, you run out of fds pretty quickly. But at least our threading
model is designed to cope with this sort of thing.
> 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...
Just the thought of trying to do multithreaded GC with the complexities of
our current garbage collector makes me turn pale. Mind you, we have someone
working on an incremental collector which is much the same principle, so it
could work. It would be great for games and interactive stuff, too.
What you probably want to do is arrange for a GC to be triggered when all
the threads are blocked on I/O, this can be done in conjunction with the
threadWait stuff.
> Anyway, thanks' for paying attention to the whining of this one little
> developer :)
No problem!
Cheers,
Simon
