Hi Andreas,

I would have to say that your implementation presented me with a very
nice hook.  Thanks!  All I had to do is install an eventQueue that
responds to #nextPut: and we were off and running.

I am attaching the most recent LindaTalk.  I have created a
LindaEventProcessor, that supplies a pumped queuing mechanism and spits
the events out based on linda style event registrations and the matching
of a tupleTemplate with the event that was stuffed into the queue by the
EventSensor.  This seems to run at ~ 130,000 events/sec on the enqueue
side.  I don't know how the event handling side is performing, but it
seems to be pretty fast.

After unzipping this tarball, please filein the following:
	EventSensor-ar.cs
	Linda-Base.X.cs
	Linda-Queues.X.cs
	Linda-VM-Events.X.cs
This will open a workspace with commands that installs the
LindaEventProcessor for 30 seconds only, or perminently.  It *does*
register a KeyboardEventHandler since your code redirects all keyboard
traffic to the queue if one exists.  There is also a command, in the
workspace, to install a TestMouseEventHandler.  Your EventSensor handles
current mouse events and also queues them.  This MouseHandler evals
'Smalltalk beep' whenever a mouse event comes in.  You can also
uninstall it.  Does you think this performs well enough for the
potential volume of event traffic?  

Do you like the registration semantics?  I think we can give Object the
Tuple interface and override the #match: method where we need to.  This
means that the target events and the registered tuple templates can be
different classes and so we could have Registrations (like
MouseEventRegistration) as the template, and it will #match: the
incoming events.

I think I can see my way clear to writing an event based socket plugin
and have a LindaSocket that registers to this queue based on EventType
and the SocketHandleId and the read/write/exception flags.  The data can
be buffered separately and the callback would cause the socket to go get
data, or write data.  Doing this so that the vm is backward compatible
is the real trick I think.

I also refactored the EventTupleSpace to use the LindaEventProcessor for
it's event engine.  It solved a deadlock/starvation problem and cleaned
up the code considerably.  I am now getting around 700 tuples/sec into
the EventTupleSpace (this is with 3 eventThreads and a producer and a
consumer thread).

Rob


"Raab, Andreas" wrote:
> 
> Folks,
> 
> After looking at Tim's EventSensor stuff I figured that there are a couple
> of things that I don't like (no pun intended). So I took a little time and
> rewrote it the way I think it should be done. Attached is the corresponding
> change set which you can file in into any Squeak version (I tested it only
> with 2.9a but I strongly believe it'll work with any Squeak). Here are the
> major differences:
> 
> * InputSensor compatibility
> The provided EventSensor gives you full compatibility with InputSensor. It
> allows to implement either the (old) state based API (that is #primMousePt,
> #primMouseButtons, #primKbdPeek, #primKbdNext, #primInterruptSemaphore etc.)
> or a new event based API, consisting of only two new primitives (one of
> those optional).
> 
> * Decoupling Morphic and Events
> Events are not automatically converted into MorphicEvents but stored as
> "raw" data. I figured that some people might be interested in packaging
> event in different ways so that there's no point in converting the events
> before knowing in which context they're used.
> 
> * A somewhat different event format
> I've added support for time stamps (which we will need for determining
> double-click times etc) for all events, as well as a number of currently
> "reserved" slots for the defined events. I think that we may want to use
> these reserved slots for stuff like a window handle, Unicode characters, or
> meta-keys (such as function keys or similar).
> 
> How does it work?! First of all, the provided EventSensor basically shadows
> the "old" primitives with instance state. Since these primitives have been
> state based anyways, the EventSensor simply replicates this particular part
> of the C support code, (pre-)processing events as they come in and updating
> the state as required. Thus, whenever you ask for "Sensor mousePoint" you
> will get the latest mouse position regardless of the events still in the
> queue. This is useful since most users of Sensor use want to see a quick
> snapshot of the current state rather than an outdated state from possibly
> several hundred milliseconds before.
> 
> Events itself are read in by a process running at #lowIOPriority. This
> process waits either waits for a specified amount of milliseconds between
> looking for more events or can be triggered by an event semaphore. You may
> ask why I'm using two mechanisms here but the answer is simple. Most VMs
> will not support true asynchronous notifications about events so we do have
> to poll at some point. If, however, the VM does support async event
> notification, the semaphore can be used to signal incoming events. The
> design of the EventSensor allows for both mechanisms.
> 
> Whenever an event comes in, it is processed by the EventSensor. Processing
> means to update the current state so that it reflects the state that would
> be reported by InputSensor. Also - given that an event queue is present -
> the event gets queued up there, allowing clients to retrieve the events in
> order. Therefore, you can use both approaches either the state based
> protocol of InputSensor or an event based protocol (such as for morphic).
> The only difference is that you have to install an event queue if you wish
> to process the events yourself.
> 
> User interrupts. These are handled by the ioProcess running in EventSensor.
> Again, this is basically a replication of the functionality that was
> formerly carried out by the VM support code. If EventSensor receives a
> keyboard event which represents the interrupt key, then it signals the user
> interrupt semaphore. A small but important side note here is that because
> the interrupt watcher runs at #userInterruptPriority and the ioProcess of
> the EventSensor runs at #lowIOPriority, the interrupt watcher process will
> *not* interrupt the low-level event process but only processes running at
> regular user priority. Again, this is the same behavior as before so it's
> completely compatible with the internals of the InputSensor primitive set we
> have today.
> 
> I'm sending this CS as a base for discussions. If you wish to try it out,
> all you have to do is to file it in and execute "EventSensor install" and
> everything should keep going just as before. As of now, the primitive
> support for the two new primitives is not provided since I'm still trying to
> figure out how to prevent the C support code from creating raw oops (another
> thing I don't like is that with Tims implementation you have to create oops
> yourself).
> 
> Comments are, of course, very welcome.
> 
>   - Andreas
> 
>   ------------------------------------------------------------------------
>                         Name: EventSensor-ar.cs
>    EventSensor-ar.cs    Type: unspecified type (application/octet-stream)
>                     Encoding: quoted-printable

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linda-events-a4.tgz
Type: application/octet-stream
Size: 23392 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20000730/e2d094da/linda-events-a4.obj