A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-fn.1294.mcz
==================== Summary ====================
Name: Kernel-fn.1294 Author: fn Time: 29 January 2020, 6:47:12.028071 pm UUID: 0b61cdfe-41e2-4aee-a5f0-80d8e7d45127 Ancestors: Kernel-tonyg.1293
Remove inputSemaphore and hasInputSemaphore from EventSensor (both are no longer in use). Also drop EventSensor>>primSetInputSemaphore:.
=============== Diff against Kernel-tonyg.1293 ===============
Item was changed: Object subclass: #EventSensor + instanceVariableNames: 'mouseButtons mousePosition mouseWheelDelta keyboardBuffer interruptKey interruptSemaphore eventQueue lastEventPoll' - instanceVariableNames: 'mouseButtons mousePosition mouseWheelDelta keyboardBuffer interruptKey interruptSemaphore eventQueue inputSemaphore lastEventPoll hasInputSemaphore' classVariableNames: 'ButtonDecodeTable EventPollPeriod EventTicklerProcess InterruptSemaphore InterruptWatcherProcess KeyDecodeTable' poolDictionaries: 'EventSensorConstants' category: 'Kernel-Processes'!
!EventSensor commentStamp: 'mt 12/13/2019 14:38' prior: 0! An EventSensor is an interface to the user input devices. There is at least one instance of EventSensor named Sensor in the system.
EventSensor is a replacement for the earlier InputSensor implementation based on a set of (optional) event primitives. An EventSensor updates its state when events are received so that all state based users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor mouseButtons) will work exactly as before, by moving the current VM mechanisms into EventSensor itself. An optional input semaphore is part of the new design.
For platforms that support true asynchronous event notification, the semaphore will be signaled to indicate pending events. On platforms that do not support asynchronous notifications about events, the UI will have to poll EventSensor periodically to read events from the VM.
Instance variables: mouseButtons <Integer> - mouse button state as replacement for primMouseButtons mousePosition <Point> - mouse position as replacement for primMousePt keyboardBuffer <SharedQueue> - keyboard input buffer interruptKey <Integer> - currently defined interrupt key interruptSemaphore <Semaphore> - the semaphore signaled when the interruptKey is detected eventQueue <SharedQueue> - an optional event queue for event driven applications inputSemaphore <Semaphore>- the semaphore signaled by the VM if asynchronous event notification is supported lastEventPoll <Integer> - the last millisecondClockValue at which we called fetchMoreEvents hasInputSemaphore <Boolean> - true if my inputSemaphore has actually been signaled at least once.
Class variables: ButtonDecodeTable <ByteArray> - maps mouse buttons as reported by the VM to ones reported in the events. KeyDecodeTable <Dictionary<SmallInteger->SmallInteger>> - maps some keys and their modifiers to other keys (used for instance to map Ctrl-X to Alt-X) InterruptSemaphore <Semaphore> - signalled by the the VM and/or the event loop upon receiving an interrupt keystroke. InterruptWatcherProcess <Process> - waits on the InterruptSemaphore and then responds as appropriate. EventPollPeriod <Integer> - the number of milliseconds to wait between polling for more events in the userInterruptHandler. EventTicklerProcess <Process> - the process that makes sure that events are polled for often enough (at least every EventPollPeriod milliseconds).
Event format: The current event format is very simple. Each event is recorded into an 8 element array. All events must provide some SmallInteger ID (the first field in the event buffer) and a time stamp (the second field in the event buffer), so that the difference between the time stamp of an event and the current time can be reported.
Currently, the following events are defined:
Null event ============= The Null event is returned when the ST side asks for more events but no more events are available. Structure: [1] - event type 0 [2-8] - unused
Mouse event structure ========================== Mouse events are generated when mouse input is detected. [1] - event type 1 [2] - time stamp [3] - mouse x position [4] - mouse y position [5] - button state; bitfield with the following entries: 1 - 2r001 yellow (e.g., right) button 2 - 2r010 blue (e.g., middle) button 4 - 2r100 red (e.g., left) button [all other bits are currently undefined] [6] - modifier keys; bitfield with the following entries: 1 - shift key 2 - ctrl key 4 - (Mac specific) option key 8 - Cmd/Alt key [all other bits are currently undefined] [7] - reserved. [8] - host window id.
Keyboard events ==================== Keyboard events are generated when keyboard input is detected. [1] - event type 2 [2] - time stamp [3] - character code (Ascii) For now the character code is in Mac Roman encoding. See #macToSqueak. For key press/release (see [4]), character codes are normalized. [4] - press state; integer with the following meaning 0 - character (aka. key stroke or key still pressed) 1 - key press (aka. key down) 2 - key release (aka. key up) [5] - modifier keys (same as in mouse events) For key press/release (see [4]), modifier keys are still accessible. [6] - character code (Unicode UTF32) Manual decoding via KeyboardInputInterpreter possible. For key press/release (see [4]), character codes are normalized. [7] - reserved. [8] - host window id. Mouse-wheel event structure ========================== Mouse-wheel events are generated when mouse-wheel input is detected. [1] - event type 7 [2] - time stamp [3] - horizontal scroll delta [4] - vertical scroll delta [5] - button state (same as in mouse events) [6] - modifier keys (same as in mouse events) [7] - reserved. [8] - host window id. !
Item was changed: ----- Method: EventSensor>>fetchMoreEvents (in category 'private-I/O') ----- fetchMoreEvents "Fetch more events from the VM" | eventBuffer type |
- "Reset input semaphore so clients can wait for the next events after this one." - inputSemaphore isSignaled - ifTrue: [ hasInputSemaphore := true. - inputSemaphore initSignals ]. - "Remember the last time that I checked for events." lastEventPoll := Time millisecondClockValue.
eventBuffer := Array new: 8. [self primGetNextEvent: eventBuffer. type := eventBuffer at: 1. type = EventTypeNone] whileFalse: [self processEvent: eventBuffer]. !
Item was changed: ----- Method: EventSensor>>initialize (in category 'initialize') ----- initialize "Initialize the receiver" mouseButtons := 0. mousePosition := 0 @ 0. mouseWheelDelta := 0 @ 0. keyboardBuffer := SharedQueue new. self setInterruptKey: (interruptKey ifNil: [$. asciiValue bitOr: 16r0800 ]). "cmd-." interruptSemaphore := (Smalltalk specialObjectsArray at: 31) ifNil: [Semaphore new]. + self flushAllButDandDEvents.! - self flushAllButDandDEvents. - inputSemaphore := Semaphore new. - hasInputSemaphore := false.!
Item was removed: - ----- Method: EventSensor>>primSetInputSemaphore: (in category 'private-I/O') ----- - primSetInputSemaphore: semaIndex - "Set the input semaphore the VM should use for asynchronously signaling the availability of events. Primitive. Optional." - <primitive: 93> - ^nil!
Item was changed: ----- Method: EventSensor>>shutDown (in category 'initialize') ----- shutDown
InterruptWatcherProcess ifNotNil: [ InterruptWatcherProcess terminate. InterruptWatcherProcess := nil ].
EventTicklerProcess ifNotNil: [ EventTicklerProcess terminate. + EventTicklerProcess := nil. ].! - EventTicklerProcess := nil. ]. - - inputSemaphore ifNotNil:[Smalltalk unregisterExternalObject: inputSemaphore].!
Item was changed: ----- Method: EventSensor>>startUp (in category 'initialize') ----- startUp
self initialize. - self primSetInputSemaphore: (Smalltalk registerExternalObject: inputSemaphore).
self installInterruptWatcher. self installEventTickler.
+ Smalltalk isMorphic ifTrue: [self flushAllButDandDEvents].! - Smalltalk isMorphic ifTrue: [self flushAllButDandDEvents]. - - "Attempt to discover whether the input semaphore is actually being signaled." - hasInputSemaphore := false. - inputSemaphore initSignals.!
On 29/01/20 5:47 PM, commits@source.squeak.org wrote:
inputSemaphore <Semaphore>- the semaphore signaled by the VM if asynchronous event notification is supported
..
hasInputSemaphore <Boolean> - true if my inputSemaphore has actually been signaled at least once.
Shouldn't the patch delete references to the eliminated ivars in the comments too?
Regards .. Subbu
On Wed, Jan 29, 2020 at 05:47:15PM +0000, commits@source.squeak.org wrote:
A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-fn.1294.mcz
==================== Summary ====================
Name: Kernel-fn.1294 Author: fn Time: 29 January 2020, 6:47:12.028071 pm UUID: 0b61cdfe-41e2-4aee-a5f0-80d8e7d45127 Ancestors: Kernel-tonyg.1293
Remove inputSemaphore and hasInputSemaphore from EventSensor (both are no longer in use). Also drop EventSensor>>primSetInputSemaphore:.
Is it actually the case that inputSemaphore and hasInputSemaphore are no longer in use? They appear to be used now in exactly the same way they were used in Squeak 3.8. But in Squeak 3.6, the inputSemaphore was waited on by an ioProcess, so it looks like it served a useful purpose back then.
So yes, this actually does appear to be dead code that has been waiting all these years for cleanup :-)
Dave
As best I can recall we used to signal the input sem from the vm when a key event came in. We also used to signal a specific interrupt key semaphore, which had the great virtue of really making sure the image got the message that you wanted it to stop chewing gum and pay attention *right now*young fella.
On 2020-01-29, at 5:00 PM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jan 29, 2020 at 05:47:15PM +0000, commits@source.squeak.org wrote:
A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-fn.1294.mcz
==================== Summary ====================
Name: Kernel-fn.1294 Author: fn Time: 29 January 2020, 6:47:12.028071 pm UUID: 0b61cdfe-41e2-4aee-a5f0-80d8e7d45127 Ancestors: Kernel-tonyg.1293
Remove inputSemaphore and hasInputSemaphore from EventSensor (both are no longer in use). Also drop EventSensor>>primSetInputSemaphore:.
Is it actually the case that inputSemaphore and hasInputSemaphore are no longer in use? They appear to be used now in exactly the same way they were used in Squeak 3.8. But in Squeak 3.6, the inputSemaphore was waited on by an ioProcess, so it looks like it served a useful purpose back then.
So yes, this actually does appear to be dead code that has been waiting all these years for cleanup :-)
Dave
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother," said Pooh, reading his bank statement from Barings.
Hi all,
I think Tim is correct and this is an old artifact from the previous and semaphore-based event mechanism.
Does anyone object to merging this into trunk (with the class comment fixed of course)? It's a simple cleanup, not a new feature.
Fabio
On Thu, Jan 30, 2020 at 2:31 AM tim Rowledge tim@rowledge.org wrote:
As best I can recall we used to signal the input sem from the vm when a key event came in. We also used to signal a specific interrupt key semaphore, which had the great virtue of really making sure the image got the message that you wanted it to stop chewing gum and pay attention *right now*young fella.
On 2020-01-29, at 5:00 PM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jan 29, 2020 at 05:47:15PM +0000, commits@source.squeak.org
wrote:
A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-fn.1294.mcz
==================== Summary ====================
Name: Kernel-fn.1294 Author: fn Time: 29 January 2020, 6:47:12.028071 pm UUID: 0b61cdfe-41e2-4aee-a5f0-80d8e7d45127 Ancestors: Kernel-tonyg.1293
Remove inputSemaphore and hasInputSemaphore from EventSensor (both are
no longer in use). Also drop EventSensor>>primSetInputSemaphore:.
Is it actually the case that inputSemaphore and hasInputSemaphore are no longer in use? They appear to be used now in exactly the same way they were used in Squeak 3.8. But in Squeak 3.6, the inputSemaphore was waited on by an ioProcess, so it looks like it served a useful purpose back then.
So yes, this actually does appear to be dead code that has been waiting all these years for cleanup :-)
Dave
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother," said Pooh, reading his bank statement from Barings.
I tried to find more information about the semaphore based approach, and to me it seems that sometime somewhere someone decided it's a good idea to poll instead of waiting for a semaphore. So, the semaphore is signaled by the VM when a new event is available (I tested it on linux, and according to emails, Andreas fixed it for windows back in 2009), but the image doesn't use the semaphore. I tried to understand how the delay of 500ms gets worked around and the events not get stalled, but I couldn't.
I see no point in polling for events when we have a semaphore available. So, I think we should investigate whether polling is really a better choice than the semaphore.
Levente
On Mon, 3 Feb 2020, Fabio Niephaus wrote:
Hi all,
I think Tim is correct and this is an old artifact from the previous and semaphore-based event mechanism.
Does anyone object to merging this into trunk (with the class comment fixed of course)? It's a simple cleanup, not a new feature.
Fabio
On Thu, Jan 30, 2020 at 2:31 AM tim Rowledge tim@rowledge.org wrote: As best I can recall we used to signal the input sem from the vm when a key event came in. We also used to signal a specific interrupt key semaphore, which had the great virtue of really making sure the image got the message that you wanted it to stop chewing gum and pay attention *right now*young fella.
> On 2020-01-29, at 5:00 PM, David T. Lewis <lewis@mail.msen.com> wrote: > > On Wed, Jan 29, 2020 at 05:47:15PM +0000, commits@source.squeak.org wrote: >> A new version of Kernel was added to project The Inbox: >> http://source.squeak.org/inbox/Kernel-fn.1294.mcz >> >> ==================== Summary ==================== >> >> Name: Kernel-fn.1294 >> Author: fn >> Time: 29 January 2020, 6:47:12.028071 pm >> UUID: 0b61cdfe-41e2-4aee-a5f0-80d8e7d45127 >> Ancestors: Kernel-tonyg.1293 >> >> Remove inputSemaphore and hasInputSemaphore from EventSensor (both are no longer in use). Also drop EventSensor>>primSetInputSemaphore:. >> > > Is it actually the case that inputSemaphore and hasInputSemaphore are > no longer in use? They appear to be used now in exactly the same way > they were used in Squeak 3.8. But in Squeak 3.6, the inputSemaphore was > waited on by an ioProcess, so it looks like it served a useful purpose > back then. > > So yes, this actually does appear to be dead code that has been waiting > all these years for cleanup :-) > > Dave > > > tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother," said Pooh, reading his bank statement from Barings.
Thanks to Squeak.js, I was able to trace this back to Squeak 1.13u [1] when EventSensor was called "InputState" (see screenshot below). At that time, the semaphore was in use and that also explains why Squeak.js is supporting it. I also found some details on polling vs. event loop in VisualWorks (see [2], "3.5.1. How User-Interface Events Work in VisualWorks"). There are some other related discussions (e.g. [3]), I have the feeling that there was a good reason to move from an event to a polling loop.
May I suggest we clean the code up for 5.3 now, and experiment with an event-based loop after the release?
Fabio
[1] https://squeak.js.org/run/#url=https://freudenbergs.de/bert/squeakjs&fil... [2] https://joeyoder.com/Research/cblend-doc/index2.html [3] http://forum.world.st/Discard-the-event-tickler-process-tp4888251p4888291.ht...
[image: image.png]
On Tue, Feb 4, 2020 at 1:40 PM Levente Uzonyi leves@caesar.elte.hu wrote:
I tried to find more information about the semaphore based approach, and to me it seems that sometime somewhere someone decided it's a good idea to poll instead of waiting for a semaphore. So, the semaphore is signaled by the VM when a new event is available (I tested it on linux, and according to emails, Andreas fixed it for windows back in 2009), but the image doesn't use the semaphore. I tried to understand how the delay of 500ms gets worked around and the events not get stalled, but I couldn't.
I see no point in polling for events when we have a semaphore available. So, I think we should investigate whether polling is really a better choice than the semaphore.
Levente
On Mon, 3 Feb 2020, Fabio Niephaus wrote:
Hi all,
I think Tim is correct and this is an old artifact from the previous and
semaphore-based event mechanism.
Does anyone object to merging this into trunk (with the class comment
fixed of course)? It's a simple cleanup, not a new feature.
Fabio
On Thu, Jan 30, 2020 at 2:31 AM tim Rowledge tim@rowledge.org wrote: As best I can recall we used to signal the input sem from the vm
when a key event came in. We also used to signal a specific interrupt key semaphore, which had the great virtue of really making sure the image got
the message that you wanted it to stop chewing gum and pay
attention *right now*young fella.
> On 2020-01-29, at 5:00 PM, David T. Lewis <lewis@mail.msen.com>
wrote:
> > On Wed, Jan 29, 2020 at 05:47:15PM +0000,
commits@source.squeak.org wrote:
>> A new version of Kernel was added to project The Inbox: >> http://source.squeak.org/inbox/Kernel-fn.1294.mcz >> >> ==================== Summary ==================== >> >> Name: Kernel-fn.1294 >> Author: fn >> Time: 29 January 2020, 6:47:12.028071 pm >> UUID: 0b61cdfe-41e2-4aee-a5f0-80d8e7d45127 >> Ancestors: Kernel-tonyg.1293 >> >> Remove inputSemaphore and hasInputSemaphore from EventSensor
(both are no longer in use). Also drop EventSensor>>primSetInputSemaphore:.
>> > > Is it actually the case that inputSemaphore and
hasInputSemaphore are
> no longer in use? They appear to be used now in exactly the same
way
> they were used in Squeak 3.8. But in Squeak 3.6, the
inputSemaphore was
> waited on by an ioProcess, so it looks like it served a useful
purpose
> back then. > > So yes, this actually does appear to be dead code that has been
waiting
> all these years for cleanup :-) > > Dave > > > tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother," said Pooh, reading his bank statement from Barings.
Ah, the joys of ancient history...
On 2020-02-04, at 11:49 AM, Fabio Niephaus lists@fniephaus.com wrote:
Thanks to Squeak.js, I was able to trace this back to Squeak 1.13u [1] when EventSensor was called "InputState" (see screenshot below).
Yes, the really old InputState stuff was a bit different. And it was a really, really, long time ago so the details are a bit fuzzy.
What used to happen was the VM would signal the InputSemaphore each time an event came in. A separate InterruptSemaphore was used for when the cmd-. was used although that was actually supposed to be configurable, with a specific primitive etc but I don't think it ever was changed by anyone.
Remember, back then we had most OS/GUIs not working pre-emptively; Mac OS, Windows & RISC OS were all some variety of cooperative tasking to varying degrees. Threading wasn't exactly sometihng one would use much. So what we used was a count of message sends and backward branches to decide when to check for any need to swap Smalltalk processes around and to decide whether to check for any OS events. It could get complicated trying to work out a good heuristic and it was unlikely to be the same for all platforms. For example on RISC OS the general practice was for an application to ask for any events with an API that was also in effect an offer to give up control to any other applications. So one would call that as often as possible and also only ask for important events as a way of giving all apps plenty of cpu time. Of course, Squeak wants to run all the time in order to do Morphic animation etc and so that rather got in the way. Windows had some issues about a short event queue that could overflow, I think.
All this made it a bit messy to work out when to actually check for input events and how, so John, Ian, Andreas & I had many long and loud discussions about what to do. At some point we agreed on a new way involving something roughly like what now exists. IIRC the 500mS wait thing was a way to make sure that a check was done at least that often, largely as a way of keeping systems like RISC OS happy. Windows & Mac had by this time moved to sometihng like proper pre-emptive multi-tasking.
One significant downside to the change, in my opinion, is that handling the interrupt is now sometihng entirely done by checking incoming key events, which means that anything causing problems in input event handling will cause delays in getting to the interrupt. I'm fairly sure (without any solid evidence, admittedly) that we'd better off with the direct semaphore back in use; faster response to the "stop now, stooooop you damn thing stoooooop" key.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: HEM: Hide Evidence of Malfunction
On Tue, Feb 4, 2020 at 9:30 PM tim Rowledge tim@rowledge.org wrote:
Ah, the joys of ancient history...
On 2020-02-04, at 11:49 AM, Fabio Niephaus lists@fniephaus.com wrote:
Thanks to Squeak.js, I was able to trace this back to Squeak 1.13u [1]
when EventSensor was called "InputState" (see screenshot below).
Yes, the really old InputState stuff was a bit different. And it was a really, really, long time ago so the details are a bit fuzzy.
What used to happen was the VM would signal the InputSemaphore each time an event came in. A separate InterruptSemaphore was used for when the cmd-. was used although that was actually supposed to be configurable, with a specific primitive etc but I don't think it ever was changed by anyone.
Remember, back then we had most OS/GUIs not working pre-emptively; Mac OS, Windows & RISC OS were all some variety of cooperative tasking to varying degrees. Threading wasn't exactly sometihng one would use much. So what we used was a count of message sends and backward branches to decide when to check for any need to swap Smalltalk processes around and to decide whether to check for any OS events. It could get complicated trying to work out a good heuristic and it was unlikely to be the same for all platforms. For example on RISC OS the general practice was for an application to ask for any events with an API that was also in effect an offer to give up control to any other applications. So one would call that as often as possible and also only ask for important events as a way of giving all apps plenty of cpu time. Of course, Squeak wants to run all the time in order to do Morphic animation etc and so that rather got in the way. Windows had some issues about a short event queue that could overflow, I think.
All this made it a bit messy to work out when to actually check for input events and how, so John, Ian, Andreas & I had many long and loud discussions about what to do. At some point we agreed on a new way involving something roughly like what now exists. IIRC the 500mS wait thing was a way to make sure that a check was done at least that often, largely as a way of keeping systems like RISC OS happy. Windows & Mac had by this time moved to sometihng like proper pre-emptive multi-tasking.
One significant downside to the change, in my opinion, is that handling the interrupt is now sometihng entirely done by checking incoming key events, which means that anything causing problems in input event handling will cause delays in getting to the interrupt. I'm fairly sure (without any solid evidence, admittedly) that we'd better off with the direct semaphore back in use; faster response to the "stop now, stooooop you damn thing stoooooop" key.
Hang on, isn't this what the interrupt watcher is for (see #installInterruptWatcher)? And as you mentioned, we are still using a separate InterruptSemaphore to this day.
Since we haven't been using the input semaphore for a really long time, this will require some rigorous testing. Who knows the VMs are doing the right thing?
Fabio
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: HEM: Hide Evidence of Malfunction
It works like this:
At startUp time, the Sensor (an instance of EventSensor) registers its input semaphore in the external objects array, and informs the VM of the index of that semaphore:
self primSetInputSemaphore: (Smalltalk registerExternalObject: inputSemaphore).
Once this is done, the VM is able to use the standard signalSemaphoreWithIndex() mechanism to signal the semaphore wnenever a new input event is available.
All if this code is present in both the image and the VM, and presumably is working as originally intended in all modern VMs and images (but yes, it needs some testing by now).
On the image side, the Sensor has a SharedQueue called eventQueue that holds available events. It reads from the queue queue to provide events to the image (e.g. Morphic or MVC user interface).
The issue at hand is how the eventQueue gets populated in real time. In principle, we would want this to be driven by inputSemaphore notifications, backed up by the event tickler process to guard against lost signals.
In practice today, I am not entirely certain how it works, although it appears to be a mashup of polling mechanisms. If I terminate the event tickler process (which should be nothing more than a safety net), the image still works but is seriously degraded in reponsiveness. So the event tickler is clearly providing a lot of the inputs. The remaining event inputs probably come from EventSensor>>nextEventFromQueue calling fetchMoreEvents.
As Levente suggests, we need to understand this better. But I have to suspect that the intended design was to have a process waiting on the inputSemaphore and populating the event queue when the semaphore is signalled. Surely that basic mechanism would still need to have the separate event tickler process to guarantee safety when semaphore notifications are lost, but I would expect that the inputSemaphore could provide the primary mechanism for keeping the eventQueue filled.
I think that enough pieces are already in place that we can easily do some experimenting with this without any VM twiddling.
I would suggest not cleaning up the code for 5.3 now, simply because the unused code provides some context for the original design intent.
Dave
On Tue, Feb 04, 2020 at 08:49:13PM +0100, Fabio Niephaus wrote:
Thanks to Squeak.js, I was able to trace this back to Squeak 1.13u [1] when EventSensor was called "InputState" (see screenshot below). At that time, the semaphore was in use and that also explains why Squeak.js is supporting it. I also found some details on polling vs. event loop in VisualWorks (see [2], "3.5.1. How User-Interface Events Work in VisualWorks"). There are some other related discussions (e.g. [3]), I have the feeling that there was a good reason to move from an event to a polling loop.
May I suggest we clean the code up for 5.3 now, and experiment with an event-based loop after the release?
Fabio
[1] https://squeak.js.org/run/#url=https://freudenbergs.de/bert/squeakjs&fil... [2] https://joeyoder.com/Research/cblend-doc/index2.html [3] http://forum.world.st/Discard-the-event-tickler-process-tp4888251p4888291.ht...
[image: image.png]
On Tue, Feb 4, 2020 at 1:40 PM Levente Uzonyi leves@caesar.elte.hu wrote:
I tried to find more information about the semaphore based approach, and to me it seems that sometime somewhere someone decided it's a good idea to poll instead of waiting for a semaphore. So, the semaphore is signaled by the VM when a new event is available (I tested it on linux, and according to emails, Andreas fixed it for windows back in 2009), but the image doesn't use the semaphore. I tried to understand how the delay of 500ms gets worked around and the events not get stalled, but I couldn't.
I see no point in polling for events when we have a semaphore available. So, I think we should investigate whether polling is really a better choice than the semaphore.
Levente
On Mon, 3 Feb 2020, Fabio Niephaus wrote:
Hi all,
I think Tim is correct and this is an old artifact from the previous and
semaphore-based event mechanism.
Does anyone object to merging this into trunk (with the class comment
fixed of course)? It's a simple cleanup, not a new feature.
Fabio
On Thu, Jan 30, 2020 at 2:31 AM tim Rowledge tim@rowledge.org wrote: As best I can recall we used to signal the input sem from the vm
when a key event came in. We also used to signal a specific interrupt key semaphore, which had the great virtue of really making sure the image got
the message that you wanted it to stop chewing gum and pay
attention *right now*young fella.
> On 2020-01-29, at 5:00 PM, David T. Lewis <lewis@mail.msen.com>
wrote:
> > On Wed, Jan 29, 2020 at 05:47:15PM +0000,
commits@source.squeak.org wrote:
>> A new version of Kernel was added to project The Inbox: >> http://source.squeak.org/inbox/Kernel-fn.1294.mcz >> >> ==================== Summary ==================== >> >> Name: Kernel-fn.1294 >> Author: fn >> Time: 29 January 2020, 6:47:12.028071 pm >> UUID: 0b61cdfe-41e2-4aee-a5f0-80d8e7d45127 >> Ancestors: Kernel-tonyg.1293 >> >> Remove inputSemaphore and hasInputSemaphore from EventSensor
(both are no longer in use). Also drop EventSensor>>primSetInputSemaphore:.
>> > > Is it actually the case that inputSemaphore and
hasInputSemaphore are
> no longer in use? They appear to be used now in exactly the same
way
> they were used in Squeak 3.8. But in Squeak 3.6, the
inputSemaphore was
> waited on by an ioProcess, so it looks like it served a useful
purpose
> back then. > > So yes, this actually does appear to be dead code that has been
waiting
> all these years for cleanup :-) > > Dave > > > tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother," said Pooh, reading his bank statement from Barings.
primlnputSemaphore: (#93) is described in the Blue Book, including details on how it is supposed to be used. Since it was obviously used in the past, there must be a reason why it has evolved into what we have today. Maybe Bert knows more about that?
Fabio
On Wed, Feb 5, 2020 at 1:22 AM David T. Lewis lewis@mail.msen.com wrote:
It works like this:
At startUp time, the Sensor (an instance of EventSensor) registers its input semaphore in the external objects array, and informs the VM of the index of that semaphore:
self primSetInputSemaphore: (Smalltalk registerExternalObject: inputSemaphore).
Once this is done, the VM is able to use the standard signalSemaphoreWithIndex() mechanism to signal the semaphore wnenever a new input event is available.
All if this code is present in both the image and the VM, and presumably is working as originally intended in all modern VMs and images (but yes, it needs some testing by now).
On the image side, the Sensor has a SharedQueue called eventQueue that holds available events. It reads from the queue queue to provide events to the image (e.g. Morphic or MVC user interface).
The issue at hand is how the eventQueue gets populated in real time. In principle, we would want this to be driven by inputSemaphore notifications, backed up by the event tickler process to guard against lost signals.
In practice today, I am not entirely certain how it works, although it appears to be a mashup of polling mechanisms. If I terminate the event tickler process (which should be nothing more than a safety net), the image still works but is seriously degraded in reponsiveness. So the event tickler is clearly providing a lot of the inputs. The remaining event inputs probably come from EventSensor>>nextEventFromQueue calling fetchMoreEvents.
As Levente suggests, we need to understand this better. But I have to suspect that the intended design was to have a process waiting on the inputSemaphore and populating the event queue when the semaphore is signalled. Surely that basic mechanism would still need to have the separate event tickler process to guarantee safety when semaphore notifications are lost, but I would expect that the inputSemaphore could provide the primary mechanism for keeping the eventQueue filled.
I think that enough pieces are already in place that we can easily do some experimenting with this without any VM twiddling.
I would suggest not cleaning up the code for 5.3 now, simply because the unused code provides some context for the original design intent.
Dave
On Tue, Feb 04, 2020 at 08:49:13PM +0100, Fabio Niephaus wrote:
Thanks to Squeak.js, I was able to trace this back to Squeak 1.13u [1] when EventSensor was called "InputState" (see screenshot below). At that time, the semaphore was in use and that also explains why Squeak.js is supporting it. I also found some details on polling vs. event loop in VisualWorks (see [2], "3.5.1. How User-Interface Events Work in VisualWorks"). There are some other related discussions (e.g. [3]), I have the feeling that there was a good reason to move from an event to a polling loop.
May I suggest we clean the code up for 5.3 now, and experiment with an event-based loop after the release?
Fabio
[1] https://squeak.js.org/run/#url=https://freudenbergs.de/bert/squeakjs&fil... [2] https://joeyoder.com/Research/cblend-doc/index2.html [3] http://forum.world.st/Discard-the-event-tickler-process-tp4888251p4888291.ht...
[image: image.png]
On Tue, Feb 4, 2020 at 1:40 PM Levente Uzonyi leves@caesar.elte.hu wrote:
I tried to find more information about the semaphore based approach, and to me it seems that sometime somewhere someone decided it's a good idea to poll instead of waiting for a semaphore. So, the semaphore is signaled by the VM when a new event is available (I tested it on linux, and according to emails, Andreas fixed it for windows back in 2009), but the image doesn't use the semaphore. I tried to understand how the delay of 500ms gets worked around and the events not get stalled, but I couldn't.
I see no point in polling for events when we have a semaphore available. So, I think we should investigate whether polling is really a better choice than the semaphore.
Levente
On Mon, 3 Feb 2020, Fabio Niephaus wrote:
Hi all,
I think Tim is correct and this is an old artifact from the previous and
semaphore-based event mechanism.
Does anyone object to merging this into trunk (with the class comment
fixed of course)? It's a simple cleanup, not a new feature.
Fabio
On Thu, Jan 30, 2020 at 2:31 AM tim Rowledge tim@rowledge.org wrote: As best I can recall we used to signal the input sem from the vm
when a key event came in. We also used to signal a specific interrupt key semaphore, which had the great virtue of really making sure the image got
the message that you wanted it to stop chewing gum and pay
attention *right now*young fella.
> On 2020-01-29, at 5:00 PM, David T. Lewis <lewis@mail.msen.com>
wrote:
> > On Wed, Jan 29, 2020 at 05:47:15PM +0000,
commits@source.squeak.org wrote:
>> A new version of Kernel was added to project The Inbox: >> http://source.squeak.org/inbox/Kernel-fn.1294.mcz >> >> ==================== Summary ==================== >> >> Name: Kernel-fn.1294 >> Author: fn >> Time: 29 January 2020, 6:47:12.028071 pm >> UUID: 0b61cdfe-41e2-4aee-a5f0-80d8e7d45127 >> Ancestors: Kernel-tonyg.1293 >> >> Remove inputSemaphore and hasInputSemaphore from EventSensor
(both are no longer in use). Also drop EventSensor>>primSetInputSemaphore:.
>> > > Is it actually the case that inputSemaphore and
hasInputSemaphore are
> no longer in use? They appear to be used now in exactly the same
way
> they were used in Squeak 3.8. But in Squeak 3.6, the
inputSemaphore was
> waited on by an ioProcess, so it looks like it served a useful
purpose
> back then. > > So yes, this actually does appear to be dead code that has been
waiting
> all these years for cleanup :-) > > Dave > > > tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother," said Pooh, reading his bank statement from Barings.
I guess what happened is that Morphic uses polling as its default mechanism to do any updates (via step methods). Something is supposed to be animating all the time anyways (that's how simulations a la Etoys work) so there was no incentive to support a mostly-static event-driven interface. This was also before battery-powered devices were common so power efficiency was not a big concern.
Nowadays we do care about efficiency, so switching to an event-driven style makes sense.
Not before the release though ;)
- Bert -
On Tue, Feb 4, 2020 at 4:43 PM Fabio Niephaus lists@fniephaus.com wrote:
primlnputSemaphore: (#93) is described in the Blue Book, including details on how it is supposed to be used. Since it was obviously used in the past, there must be a reason why it has evolved into what we have today. Maybe Bert knows more about that?
Fabio
On Wed, Feb 5, 2020 at 1:22 AM David T. Lewis lewis@mail.msen.com wrote:
It works like this:
At startUp time, the Sensor (an instance of EventSensor) registers its input semaphore in the external objects array, and informs the VM of the index of that semaphore:
self primSetInputSemaphore: (Smalltalk registerExternalObject:
inputSemaphore).
Once this is done, the VM is able to use the standard
signalSemaphoreWithIndex()
mechanism to signal the semaphore wnenever a new input event is
available.
All if this code is present in both the image and the VM, and presumably is working as originally intended in all modern VMs and images (but yes, it needs some testing by now).
On the image side, the Sensor has a SharedQueue called eventQueue that holds available events. It reads from the queue queue to provide events to the image (e.g. Morphic or MVC user interface).
The issue at hand is how the eventQueue gets populated in real time. In principle, we would want this to be driven by inputSemaphore
notifications,
backed up by the event tickler process to guard against lost signals.
In practice today, I am not entirely certain how it works, although it appears to be a mashup of polling mechanisms. If I terminate the event tickler process (which should be nothing more than a safety net), the image still works but is seriously degraded in reponsiveness. So the event tickler is clearly providing a lot of the inputs. The remaining event inputs probably come from EventSensor>>nextEventFromQueue calling fetchMoreEvents.
As Levente suggests, we need to understand this better. But I have to suspect that the intended design was to have a process waiting on the inputSemaphore and populating the event queue when the semaphore is signalled. Surely that basic mechanism would still need to have the separate event tickler process to guarantee safety when semaphore notifications are lost, but I would expect that the inputSemaphore could provide the primary mechanism for keeping the eventQueue filled.
I think that enough pieces are already in place that we can easily do some experimenting with this without any VM twiddling.
I would suggest not cleaning up the code for 5.3 now, simply because the unused code provides some context for the original design intent.
Dave
On Tue, Feb 04, 2020 at 08:49:13PM +0100, Fabio Niephaus wrote:
Thanks to Squeak.js, I was able to trace this back to Squeak 1.13u [1]
when
EventSensor was called "InputState" (see screenshot below). At that
time,
the semaphore was in use and that also explains why Squeak.js is
supporting
it. I also found some details on polling vs. event loop in VisualWorks
(see
[2], "3.5.1. How User-Interface Events Work in VisualWorks"). There are some other related discussions (e.g. [3]), I have the feeling that
there
was a good reason to move from an event to a polling loop.
May I suggest we clean the code up for 5.3 now, and experiment with an event-based loop after the release?
Fabio
[1]
https://squeak.js.org/run/#url=https://freudenbergs.de/bert/squeakjs&fil...
[2] https://joeyoder.com/Research/cblend-doc/index2.html [3]
http://forum.world.st/Discard-the-event-tickler-process-tp4888251p4888291.ht...
[image: image.png]
On Tue, Feb 4, 2020 at 1:40 PM Levente Uzonyi leves@caesar.elte.hu
wrote:
I tried to find more information about the semaphore based approach,
and
to me it seems that sometime somewhere someone decided it's a good
idea
to poll instead of waiting for a semaphore. So, the semaphore is signaled by the VM when a new event is
available (I
tested it on linux, and according to emails, Andreas fixed it for
windows
back in 2009), but the image doesn't use the semaphore. I tried to understand how the delay of 500ms gets worked around and
the
events not get stalled, but I couldn't.
I see no point in polling for events when we have a semaphore
available.
So, I think we should investigate whether polling is really a better choice than the semaphore.
Levente
On Mon, 3 Feb 2020, Fabio Niephaus wrote:
Hi all,
I think Tim is correct and this is an old artifact from the
previous and
semaphore-based event mechanism.
Does anyone object to merging this into trunk (with the class
comment
fixed of course)? It's a simple cleanup, not a new feature.
Fabio
On Thu, Jan 30, 2020 at 2:31 AM tim Rowledge tim@rowledge.org
wrote:
As best I can recall we used to signal the input sem from
the vm
when a key event came in. We also used to signal a specific
interrupt key
semaphore, which had the great virtue of really making sure the
image got
the message that you wanted it to stop chewing gum and pay
attention *right now*young fella.
> On 2020-01-29, at 5:00 PM, David T. Lewis <
lewis@mail.msen.com>
wrote:
> > On Wed, Jan 29, 2020 at 05:47:15PM +0000,
commits@source.squeak.org wrote:
>> A new version of Kernel was added to project The Inbox: >> http://source.squeak.org/inbox/Kernel-fn.1294.mcz >> >> ==================== Summary ==================== >> >> Name: Kernel-fn.1294 >> Author: fn >> Time: 29 January 2020, 6:47:12.028071 pm >> UUID: 0b61cdfe-41e2-4aee-a5f0-80d8e7d45127 >> Ancestors: Kernel-tonyg.1293 >> >> Remove inputSemaphore and hasInputSemaphore from
EventSensor
(both are no longer in use). Also drop
EventSensor>>primSetInputSemaphore:.
>> > > Is it actually the case that inputSemaphore and
hasInputSemaphore are
> no longer in use? They appear to be used now in exactly
the same
way
> they were used in Squeak 3.8. But in Squeak 3.6, the
inputSemaphore was
> waited on by an ioProcess, so it looks like it served a
useful
purpose
> back then. > > So yes, this actually does appear to be dead code that has
been
waiting
> all these years for cleanup :-) > > Dave > > > tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother," said Pooh, reading his bank statement from Barings.
A look back at ancient email records shows that the initial stuff for an event based (but not event/interrupt driven) input system was sometihng I started in June 2000 (wholly khao!) and then argued over with Andreas for a couple of months (as we always did). It was definitely of the era of cooperative multitasking via GUI calls for most machines.
I don't have all the emails from then and the archive on forumworld.st only goes back to 2006; does anyone know of a complete archive? Looking at june 2000 for mails with subjects like 'events and morphic' should help.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Proof that evolution CAN go in reverse.
On Wed, Feb 05, 2020 at 05:52:19PM -0800, tim Rowledge wrote:
A look back at ancient email records shows that the initial stuff for an event based (but not event/interrupt driven) input system was sometihng I started in June 2000 (wholly khao!) and then argued over with Andreas for a couple of months (as we always did). It was definitely of the era of cooperative multitasking via GUI calls for most machines.
I don't have all the emails from then and the archive on forumworld.st only goes back to 2006; does anyone know of a complete archive? Looking at june 2000 for mails with subjects like 'events and morphic' should help.
Our archives on http://lists.squeakfoundation.org/pipermail/squeak-dev/ provide a history of most of the early squeak-dev email traffic going back to maybe late 1997 or so. Some of the email time stamps are suspect, but there is quite a bit there, so you may be able to browse through that site and find some things of interest.
Some of us (including me) probably have private copies of much of the early list emails, but the http://lists.squeakfoundation.org/pipermail/squeak-dev/ would be the best place to start looking.
Ian Piumarta could probably clarify the details wrt design intent, although I don't know how to reach him at the moment.
To some extent, the design intent is self evident. The sensor uses a SharedQueue to deliver events to the image, and the VM somehow populates the queue without any knowledge of how the events are to be consumed from the queue.
Twenty years ago we had platform restrictions, but nowadays your cell phone knows how to do multitasking and event handling. All that we need to do today is figure out how to cause events from the VM (SqueakJS or compiled VM) to be pushed into the sensor's event queue. It's OK to keep an event tickler process as an extra safety net, but in theory this should not even be needed.
Long ago this stuff was difficult. Today, maybe not so much. I guess let's try it and find out.
Dave
squeak-dev@lists.squeakfoundation.org