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.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: HEM: Hide Evidence of Malfunction