[squeak-dev] The Inbox: Kernel-fn.1294.mcz

Bert Freudenberg bert at freudenbergs.de
Wed Feb 5 01:15:46 UTC 2020


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 at 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 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.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> >
> >
> >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200204/9c7ec108/attachment.html>


More information about the Squeak-dev mailing list