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 at 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&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.
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
>
>
>
> >
>
>