sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
writes:
> Most of those programs can be written much more elegantly using
> multiple threads, which is the recommended method with scsh 0.6.
I have to disagree about threads beating events.
First of all, in a system where you have true closures, events are
pretty elegant. Their essence is the callback function, and callback
functions are elegant in a language like scheme (unlike in C where
event driven code is somewhat clunky because closures are simulated by
saying "call my function with this structure so it can maintain an
execution environment").
Second of all, the research on the topic at this point is pretty
conclusive -- implementing large multi-client servers on event driven
platforms scales well, and on thread based systems scales quite
poorly. See, for example, the research by Provos et al on web server
performance. No multi-threaded solution can compete with event driven
solutions. As what I'm writing is a large multi-client server, the
choice of paradigms is obvious.
(If you think about this, it actually makes complete sense -- making a
thread switch as cheap as a procedure call has proven very difficult
at best in spite of many years of research on the subject -- even in
scheduler activation style threads systems the overhead is pretty
high. Given this, the resources consumed by a thread are inevitably
going to be a lot higher than those consumed by a procedure call. Now
admittedly, if you are doing your software in scheme, at the moment
the performance of the interpreter drags you down pretty quickly
anyway, but ultimately with good compilers and such that shouldn't be
an issue. Part of what I'm doing in the project I'm trying to write is
to show that it is a lot easier to produce good network code in a
language like scheme than in C.)
Third, let me note that event driven is the natural style in which to
write GUI driven applications, and that virtually all GUI toolkits use
the event driven style for that reason. If you want to build GUIs, you
need events.
Lastly, having written large multi-client servers in the past, let me
note that event driven systems are *much* easier to write correctly
once you are used to the style. Sure, the style is a little different,
but then again, isn't Lisp a little different too, and doesn't it take
some getting used to? It is true that writing in this style in
ordinary languages sometimes leads to ugly memory finalization
problems, but luckily, we're writing in a language with garbage
collection.
Now, I must admit that when I first worked with event driven systems I
was surprised and shocked by them. "What a weird way to program!" I
thought. However, that's just because people are all taught a more
linear styles of programming. As I've noted, the shock of writing in
an event driven style is hardly worse than the shock of discovering
you can create functions on the fly and pass them around, something
many languages won't let you do.
> We're slowly working towards a much more general, CML-style framework
> for selective communication, but it'll be a while before all of that
> is fully integrated.
What is a CML framework? (C=? ML=the language ML?)
--
Perry E. Metzger perry@piermont.com
--
"Ask not what your country can force other people to do for you..."
|