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.
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200204/e782442b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 36378 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200204/e782442b/attachment.png>