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 <leves at 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 at 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 at mail.msen.com>
> > wrote:
> > >       >
> > >       > On Wed, Jan 29, 2020 at 05:47:15PM +0000,
> > commits at 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 at rowledge.org; http://www.rowledge.org/tim
> > >       "Bother," said Pooh, reading his bank statement from Barings.
> > >
> > >
> > >
> > >
> > >
> >
> >



>