On Tue, Feb 4, 2020 at 9:30 PM tim Rowledge <tim at rowledge.org> wrote:

> Ah, the joys of ancient history...
>
>
>
> > On 2020-02-04, at 11:49 AM, Fabio Niephaus <lists at fniephaus.com> 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).
>
> Yes, the really old InputState stuff was a bit different. And it was a
> really, really, long time ago so the details are a bit fuzzy.
>
> What used to happen was the VM would signal the InputSemaphore each time
> an event came in. A separate InterruptSemaphore was used for when the cmd-.
> was used although that was actually supposed to be configurable, with a
> specific primitive etc but I don't think it ever was changed by anyone.
>
> Remember, back then we had most OS/GUIs not working pre-emptively; Mac OS,
> Windows & RISC OS were all some variety of cooperative tasking to varying
> degrees. Threading wasn't exactly sometihng one would use much. So what we
> used was a count of message sends and backward branches to decide when to
> check for any need to swap Smalltalk processes around and to decide whether
> to check for any OS events. It could get complicated trying to work out a
> good heuristic and it was unlikely to be the same for all platforms. For
> example on RISC OS the general practice was for an application to ask for
> any events with an API that was also in effect an offer to give up control
> to any other applications. So one would call that as often as possible and
> also only ask for important events as a way of giving all apps plenty of
> cpu time. Of course, Squeak wants to run all the time in order to do
> Morphic animation etc and so that rather got in the way. Windows had some
> issues about a short event queue that could overflow, I think.
>
> All this made it a bit messy to work out when to actually check for input
> events and how, so John, Ian, Andreas & I had many long and loud
> discussions about what to do. At some point we agreed on a new way
> involving something roughly like what now exists. IIRC the 500mS wait thing
> was a way to make sure that a check was done at least that often, largely
> as a way of keeping systems like RISC OS happy. Windows & Mac had by this
> time moved to sometihng like proper pre-emptive multi-tasking.
>
> One significant downside to the change, in my opinion, is that handling
> the interrupt is now sometihng entirely done by checking incoming key
> events, which means that anything causing problems in input event handling
> will cause delays in getting to the interrupt. I'm fairly sure (without any
> solid evidence, admittedly) that we'd better off with the direct semaphore
> back in use; faster response to the "stop now, stooooop you damn thing
> stoooooop" key.
>

Hang on, isn't this what the interrupt watcher is for (see
#installInterruptWatcher)? And as you mentioned, we are still using a
separate InterruptSemaphore to this day.

Since we haven't been using the input semaphore for a really long time,
this will require some rigorous testing. Who knows the VMs are doing the
right thing?

Fabio


>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: HEM: Hide Evidence of Malfunction
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200204/437802f6/attachment.html>