My understanding of events is much more basic than the others discussing this issue, but I have a naive question.
Why are low level OS events like mouse clicks and keyboard strokes treated differently from a general events mechanism? By this I mean a mechanism for passing messages to 'subscribers' whenever an object emits an event (publish-subscribe)? It seems to me that any event still has an Object from which it originates, and one or more objects that will be told the event has occurred. Why can't low and high level events share the same abstractions, and even be placed on the same event queue? I also think exception-handling has much in common with event handling (on: exception do: aBlock). The exception looks to me very much like an 'event' that the block is told about. Is it possible to fuse these three mechanisms into a common abstraction and reuse a lot of the code, or is this just wishful thinking on my part?
Peter
From: Reinier van Loon R.L.J.M.W.van.Loon@inter.nl.net To: squeak@cs.uiuc.edu squeak@cs.uiuc.edu Date: Thursday, July 01, 1999 6:06 AM Subject: Re: [ENH] OS-level events
I keep getting the impression that the event systems designed so far are only concerned with keyboard or mouse events. These events are then put in an event queue with some information regarding the event.
Why not define an event as <time, object> and event queue as a collection sorted by time? The global event (interrupt) handler detects an event on the queue (tim's work) and gets the rest of the event of the object mentioned in the event.
In this way, each object (keyboard, mouse, network, etc.) can have it's own buffer. And composite events are detected easily by comparing the time stamps.
You could even start new processes to deal with events or have different event handlers wait on the queues of the objects. No 'centralized' event queue anymore.
Just an idea.
Reinier.
Why can't low and high level events share the same abstractions, and even be placed on the same event queue? I also think exception-handling has much in common with event handling (on: exception do: aBlock). The exception looks to me very much like an 'event' that the block is told about. Is it possible to fuse these three mechanisms into a common abstraction and reuse a lot of the code, or is this just wishful thinking on my part?
Peter
I think you are definitely on to something here. If you look at exception handling from an event point of view, what you are doing is simply registering an insterest in whether a particular chain of calls results in an exceptional situation. In a sense, one method context becomes an observer of a called method context. You can even take it one step further and say that when we wait (in a synchronous call) on the result of a message send, we are registering an interest on any (there can be more than one answer from a method in a generic messaging approach) answers that a method context has to give. In fact, in playing with asynchronous messaging, I discovered that places where I would have used a "Notification" type of exception to indicate progress of a method, I could simply send multiple answers through the answer queue for a method context.
All of this leads me to believe that there is in fact a common, unified approach to messaging (where answers are concerned), exception handling, events, and dependecies.
- Stephen
Peter Smet wrote:
My understanding of events is much more basic than the others discussing this issue, but I have a naive question.
Why are low level OS events like mouse clicks and keyboard strokes treated differently from a general events mechanism? By this I mean a mechanism for passing messages to 'subscribers' whenever an object emits an event (publish-subscribe)? It seems to me that any event still has an Object from which it originates, and one or more objects that will be told the event has occurred. Why can't low and high level events share the same abstractions, and even be placed on the same event queue? I also think exception-handling has much in common with event handling (on: exception do: aBlock). The exception looks to me very much like an 'event' that the block is told about. Is it possible to fuse these three mechanisms into a common abstraction and reuse a lot of the code, or is this just wishful thinking on my part?
I'm afraid it's wishful thinking.
Events are delivered asynchronously. The event generating process is normally not the one that receives the event.
Exceptions should be delivered synchronously, to the same process that raised the exception, with access to the context at the point where the exception was raised.
Updates (subscriptions) could be delivered asynchronously, but that's not the Smalltalk tradition. Quite a bit of Smalltalk code assumes that updates are handled immediately after they're generated, before the generator executes the next line of code.
squeak-dev@lists.squeakfoundation.org
-
David M.Siegel -
Peter Smet -
Stephen Pair