scsh-users
[Top] [All Lists]

Re: select?

To: "Perry E. Metzger" <perry@piermont.com>
Subject: Re: select?
From: sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
Date: Thu, 01 Aug 2002 17:53:55 +0200
Cc: scsh@zurich.ai.mit.edu
>>>>> "Perry" == Perry E Metzger <perry@piermont.com> writes:

Perry> 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.

Perry> Second of all, the research on the topic at this point is pretty
Perry> conclusive -- implementing large multi-client servers on event driven
Perry> platforms scales well, and on thread based systems scales quite
Perry> poorly. 

This isn't the case in scsh---here, threads are much more light-weight
than in the systems you cite.  (Note also that, by using threads, you
*are* using select(2)---it's sitting right in the center of the event
loop.  Re-introducing select into scsh works off that event loop in
the same way threads are.)

Perry> Third, let me note that event driven is the natural style in which to
Perry> write GUI driven applications, and that virtually all GUI toolkits use
Perry> the event driven style for that reason. If you want to build GUIs, you
Perry> need events.

No, you don't.  Actually, writing reactive concurrent applications in
an event-driven style is a major pain.  Concurrency-based GUI systems
handle this in a much better way.  The reason why virtually all GUI
toolkits are event-based is that threads are usually too expensive in
the language implementations they're based on.  This isn't the case in
scsh.  Moreover, thread-based toolkits trivially subsume event-based
toolkits.

Perry> Lastly, having written large multi-client servers in the past, let me
Perry> note that event driven systems are *much* easier to write correctly
Perry> once you are used to the style.

Lastly, having written large multi-client servers in the past, let me
note that thread-based systems are *much* easier to write correctly
once you are used to the style.

Perry> What is a CML framework? (C=? ML=the language ML?)

Yes.  CML stands for "Concurrent ML."  It's a substrate for
message-based concurrent programming in ML.  It translates
straightforwardly into Scheme.

Normally, I'd cite John Reppy's homepage as a source for material on
CML, but that seems to be temporarily offline.  There's also

@Book{Reppy1999,
  author =       {John H. Reppy},
  title =        {Concurrent Programming in {ML}},
  publisher =    {Cambridge University Press},
  year =         1999
}

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

<Prev in Thread] Current Thread [Next in Thread>