The Inbox: Kernel-fn.1294.mcz
Locked
 
|
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, [hidden email] 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 |
Re: The Inbox: Kernel-fn.1294.mcz
|
|
In reply to this post by commits-2
On Wed, Jan 29, 2020 at 05:47:15PM +0000, [hidden email] 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 |
Re: The Inbox: Kernel-fn.1294.mcz
|
|
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 <[hidden email]> wrote: > > On Wed, Jan 29, 2020 at 05:47:15PM +0000, [hidden email] 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; [hidden email]; 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 <[hidden email]> 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. |
Re: The Inbox: Kernel-fn.1294.mcz
|
|
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 <[hidden email]> 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 <[hidden email]> wrote: > > > > On Wed, Jan 29, 2020 at 05:47:15PM +0000, [hidden email] 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; [hidden email]; 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  On Tue, Feb 4, 2020 at 1:40 PM Levente Uzonyi <[hidden email]> wrote: I tried to find more information about the semaphore based approach, and |
Re: The Inbox: Kernel-fn.1294.mcz
|
|
Ah, the joys of ancient history...
> On 2020-02-04, at 11:49 AM, Fabio Niephaus <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: HEM: Hide Evidence of Malfunction |
|
|
On Tue, Feb 4, 2020 at 9:30 PM tim Rowledge <[hidden email]> wrote: Ah, the joys of ancient history... 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
|
Re: The Inbox: Kernel-fn.1294.mcz
|
|
In reply to this post by fniephaus
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&files=[Squeak1.13u.image,Squeak1.13u.changes,SqueakV1.sources]&swapButtons=true > [2] https://joeyoder.com/Research/cblend-doc/index2.html > [3] > http://forum.world.st/Discard-the-event-tickler-process-tp4888251p4888291.html > > [image: image.png] > > On Tue, Feb 4, 2020 at 1:40 PM Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> > > wrote: > > > > > > > > On Wed, Jan 29, 2020 at 05:47:15PM +0000, > > [hidden email] 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; [hidden email]; 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 <[hidden email]> 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&files=[Squeak1.13u.image,Squeak1.13u.changes,SqueakV1.sources]&swapButtons=true > > [2] https://joeyoder.com/Research/cblend-doc/index2.html > > [3] > > http://forum.world.st/Discard-the-event-tickler-process-tp4888251p4888291.html > > > > [image: image.png] > > > > On Tue, Feb 4, 2020 at 1:40 PM Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> > > > wrote: > > > > > > > > > > On Wed, Jan 29, 2020 at 05:47:15PM +0000, > > > [hidden email] 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; [hidden email]; http://www.rowledge.org/tim > > > > "Bother," said Pooh, reading his bank statement from Barings. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
Re: The Inbox: Kernel-fn.1294.mcz
|
|
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 <[hidden email]> wrote: primlnputSemaphore: (#93) is described in the Blue Book, including |
Re: The Inbox: Kernel-fn.1294.mcz
|
|
In reply to this post by David T. Lewis
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; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Proof that evolution CAN go in reverse. |
Re: The Inbox: Kernel-fn.1294.mcz
|
|
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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |