[ENH] Alternative EventSensor
Rob Withers
slosher2 at home.com
Tue Aug 1 09:16:15 UTC 2000
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!
More information about the Squeak-dev
mailing list
|