RE: call/cc

["David Simmons" <address@hidden>]

> -----Original Message-----
> From: owner-ll1-discuss@ai.mit.edu
[mailto:owner-ll1-discuss@ai.mit.edu]
> On Behalf Of Dan Weinreb
> Sent: Wednesday, December 12, 2001 5:42 AM
> To: alex@shop.com
> Cc: alk@pobox.com; ll1-discuss@ai.mit.edu
> Subject: Re: call/cc
> 
>    Date: Tue, 11 Dec 2001 19:52:02 -0500 (Eastern Standard Time)
>    From: "S. Alexander Jacobson" <alex@shop.com>
> 
>    My only point is that there are other ways to get the same
advantage
>    without the cost in code readability (requiring the programmer to
learn
>    yet another technique).
> 
> I agree that we're diverging from the topic of this list, so I'll keep
> this short: for people who are interested in the long-standing issue
> of dealing with multiple I/O-oriented tasks concurrencly by using
> threads (or coroutines) versus writing in event-driven style; there is
> a paper that I thought was very interesting:"SDEA: An Architecture for
> Well-Conditioned Scalable Internet Services" by Matt Welsh et.
> al. from Berkeley.  It talks about how to build something like a web
> server that has to deal with huge numbers of clients, without
> suffering throughput degradation and with much more "fairness" than
> most servers currently provide.
> 
> On one hand, the vision is "really cheap threads" that has been around
> since I can rememeber seems to keep falling short; using lots of
> threads causes all kinds of overhead.  On the other hand, a purely
> event-driven style makes code very hard to read.  SEDA proposes a
> middle ground that I think looks attractive.

In QKS Smalltalk we built network i/o facilities using a mixture of
threads and events. Threads provided queues for events. Events were
posted onto a thread in (possibly prioritizable) order. Events could be
synchronous or asynchronous. Events could be specified with temporal
(timer) information.

An asynchronous event, in the true sense of the word, "interrupts" the
current thread of execution to get performed. The virtual machine
defines a number of signal/interrupt flags and thus you could
disable/block these interrupts when desired -- typically while handling
an interrupt. This mechanism was frequently used to handle
hardware/asynch-driver interrupts on our Mac Smalltalk implementation.

Synchronous events are processed by code within the thread that is
responsible for extracting events from the thread's queue and invoking
them.

Timer information indicating when the event would be placed onto the
threads event queue or, if asynchronous be executed (as an interrupt) on
the thread.

Events could be marked as one-shot, or recurrent, and that included time
period information.

An event itself specified a full message with arbitrary arguments
including algorithmic routing declarations. But often this would just be
a block (continuation+closure).
---

With these facilities it was pretty easy to build network services. It
seemed a pretty natural mixture of threading and events. Much of this
work derived from my development of Mac technologies where you had to do
everything via asynchronous events because the OS did not support thread
concepts. Having come from years of work on real-time mini-computer work
and unix activities I found this to be very painful. 

That's one reason why I built threads into the QKS Smalltalk VM. We used
this mechanism to great effect in driving multi-media (and set-top
oriented facilities) in the early 90's on the Mac. The interrupt
mechanisms allowed us to place blocks/methods (closures+continuations)
directly into QuickTime tracks and fire them off as you moved through a
timebase. But, I digress...

The TCP/IP facilities were interrupt driven providing notifications as
to various events. Where for each type of interrupt you could (and
typically did) register an event object [or just a block] with a given
stream/connection or service.

This was very convenient because it enabled active servers to hae their
environment saved (image snapshot), and when it was restarted it would
restore services [threads, listeners, etc].
======

Is the kind of mechanism I mention here for Smalltalk threads+events
similar to what you are referring to Dan?

-- Dave S. [SmallScript LLC]

SmallScript for the AOS & .NET Platforms
David.Simmons@SmallScript.com | http://www.smallscript.org