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

Levente Uzonyi leves at caesar.elte.hu
Tue Feb 4 12:40:23 UTC 2020


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


More information about the Squeak-dev mailing list