I'll combine several responses.  Linda does the demuxing of events based
on a pattern match.  Each event from the EventSensor is an 8 arity Tuple
with the first field signifying the event type.  So we register:

Sensor eventQueue whenMatch: (1 | Object | Object | ... | Object)  "8
arity match tuple"
		send: #handleVMEvent:
		to: aMouseEventHandler

We get callbacks for every event that matches that pattern.  In the case
of sockets, we could register for each socket by handle:
(3 | 21 | ...)

or we could do what Andreas pointed out: (3 | ...) and monitor all
events for Sockets.  Wouldn't it be nice to have an RPM gauge, or
whatever skin you want.  Perhaps you could show it by network interface
too.  I *love* watching the flashing lights!  SystemMonitor startFull is
cool, and I have no idea what to do with the information! ;-)

I wasn't looking at the EventSensor as a UI thing, but I suppose it is. 
We could absolutely have several queues, perhaps with security or
processing restrictions.  I agree that it would be nice to register
multiple queues, perhaps with a pattern to filter the right events.

If you (y'all) look at the LindaEventProcessor, you will see that it
uses a FixedSizeSharedPriorityQueue (just horrible isn't it?).  The
PriorityQueue is implemented using the Heap, so that's pretty fast.  The
sort block is:

[:a :b | ((a respondsTo: #priority) and: [b respondsTo: #priority])
		ifTrue: [a priority > b priority]
		ifFalse: [a hash < b hash]].

If we could ensure that all the event objects responded to priority,
then we could simplify that.  I was thinking that we could also adjust
the priority of the Process based on this or on a registered priority
for the handler.

cheers,
Rob


John M McIntosh wrote:
> 
> on 7/31/00 6:47 PM, Raab, Andreas at Andreas.Raab at disney.com wrote:
> 
> > Ned wrote:
> >> Maybe I'm missing something, but why would we want to combine
> >> dissimilar events in the same queue (sockets/input/serial?)?
> >
> > Good question ;-)
> >
> >> Wouldn't that require the queue reading process to know about
> >> each event type, or to pick through the queue for the next event of a
> >> particular type?
> >
> > The big question is who is really interested in these events?! The current
> > design of events is more or less exclusively for user input events which go
> > to some UI element. It *could* make sense to have socket/serial events go to
> > UI elements as well but in most cases the UI probably isn't interested in
> > all these things. It might, on the other hand, be interesting to allow for a
> > set of listeners which could give you some global information (such as the
> > number of connections currently open, the number of failed connection
> > attempts etc) in which case passing along these events might be the easiest
> > way of getting the information.
> >
> >> Is there some advantage to a single queue, or is it just
> >> because it's easier?
> >
> > It's actually harder to do it from the VM level (although I'm not quite sure
> > that's really what we're talking about here). It would be much simpler to
> > generate these kinds of events directly from Socket (e.g., on the ST side)
> > and pass it on to the top level input queue (managed by Sensor/Hand).
> 
> Have we thought about having different queues? And then having different
> handlers run at a different priorities so we could have say high, low ,
> normal event dispatching. This would separate out mixing events in the a
> single queue. Of course making it easy to allow a person to define a queue
> and dictate how events should be dispatch might be interesting.  Something
> about priorities of interrupts come to mind, should for example a serial
> input event wait behind the dispatching of 10 keyboard events?
> 
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
> Custom Macintosh programming & various Smalltalk dialects
> PGP Key: DSS/Diff/46FC3BE6
> Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
> ===========================================================================

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!