>>>>> "Perry" == Perry E Metzger <perry@piermont.com> writes:
Perry> The research that's been done over the years (I'll provide a
Perry> bibliography if you want) tends to indicate that thread expense is an
Perry> operating system issue far more than a language issue.
Perry, the disagreement we're having is because you have
misconceptions about the thread system in scsh. Most importantly,
threads expense is not an OS expense at all in scsh---the thread
system is userland.
Moreover, the thread systems you're citing (I believe I've read most
of the work you're referring to) are based on language implementation
paradigms different from that of scsh---specifically, regarding the
representation of continuations. This means the costs (space and
time) associated with threads in scsh are typically an order of
magnitude less than with the thread systems you're citing.
Perry> People dealing with thread systems often start out by thinking
Perry> they can make threads really cheap by doing everything in
Perry> userland without kernel assists. Handling the threads there is
Perry> potentially less expensive, but has serious problems when it
Perry> comes to properly implementing thread semantics. Things like
Perry> poor support in userland for preemption and blocking system
Perry> calls make userland thread libraries nearly impossible to get
Perry> right, not that there haven't been large numbers of tries.
It sure wasn't easy to get scsh's userland thread system right, but
(mostly thanks to the work of Richard Kelsey), it's in place now.
You also missed the main thing I was saying: there *is* a select (and
only a select) sitting right at the center of the I/O event loop. The
system-call pattern of equivalent thread-based and event-based
programs are going to be very similar.
Perry> There's another issue, of course, which is that without kernel
Perry> assists, you can't take advantage of multiple processors AT ALL.
This is another common misconception: threads-as-a-programming
paradigm and threads-for-multiprocessing are best dealt with as two
different, orthogonal concepts. Currently, scsh only utilizes the
former.
>> Moreover, thread-based toolkits trivially subsume event-based toolkits.
Perry> Could you explain that more?
In thread-based toolkits, you attach threads to widgets instead of
callbacks. So, to emulate an event-based toolkit, you simply attach
threads which invoke callbacks. (Since this is a higher-order
language, you can easily hide this in the abstractions.) The opposite
is not true because you need to make sure the event loop gets run
periodically, and you end up emulating the concurrency "by hand."
(This is still not so hard with I/O-driven programs, but many
reactive applications are not completely I/O-driven.)
Perry> Well, of course, this could just degenerate into a pissing
Perry> match. "Ease" is difficult to measure and we could both just cite
Perry> systems we'd been involved with. However, performance limits are easy
Perry> to measure. Could you give me the example of the system capable of
Perry> handling ten thousand threads? Ten thousand event driven clients I've
Perry> seen -- I've never heard tell of a system that could manage more than
Perry> a few hundred threads.
In fact, thousands of threads are typical for CML applications, and
there's no reason why that should be a problem. Sure, it's a problem
if each thread takes 2 Megabytes of address space, and it's generally
a problem with stack-based language substrates, but this is scsh.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
|