Discard the event tickler process?

Hi, there!

There used to be a time, where it was userful (on some platforms) to regularly fetch events from the VM in a separate (non-UI) process. This process is called "The Event Tickler".

However, the current implementation of EventSensor fetches new events in every necessary occasion. See all senders of #fetchMoreEvents.

The event tickler process does nothing but automate that call to "EventSensor default fetchMoreEvents", which is not necessary. Neither for current MVC nor for Morphic.

Can we get rid of that event tickler process?

To try out, file-in this and save-restart the image:
EventSensor-startUp.st

***

Or may there be some other reason? :-O The comment in EventSensor >> #eventTickler is not supportive and also wrong at the moment:

"Poll infrequently to make sure that the UI process is not been stuck.
If it has been stuck, then spin the event loop so that I can detect the
interrupt key."

There is no relation to the interrupt key at the moment. CMD+. works via a distinct semaphore. And there is no code that frequently tests for CMD+. in the image either.

Best,
Marcel

Hi, again.

Okay. Actually, you do need the event tickler for CMD+. if no other process fetches events. Seems to be some VM-specific behavior you cannot trace at Smalltalk level.

The CMD+. will not be recognized by the VM if there was no recent EventSensor >> #fetchMoreEvents. Seems to be a side-effect.

So, no. We cannot get rid of the event tickler. However, why is there an InterruptSemaphore if the event tickler could easily check for CMD+. itself? Why involve the VM at all?

Best,
Marcel

Hi, again.

The priority 50 is called "user interrupt priority." Clearly, one can interrupt all processes below the priorites of the event tickler and user interrupt watcher, which is low I/O (60).

Meaning, I can safely interrupt these do-its:

[ [] repeat ] fork.
[ [] repeat ] forkAt: Processor userInterruptPriority.
[ [] repeat ] forkAt: Processor userInterruptPriority + 9.

Best,
Marcel

> On 04-04-2016, at 7:16 AM, marcel.taeumel <[hidden email]> wrote:
> There used to be a time, where it was userful (on some platforms) to
> regularly fetch events from the VM in a separate (non-UI) process. This
> process is called "The Event Tickler”.

IIRC this is something Andreas & I developed to make sure that polling UI systems such as RISC OS could reliably work. It’s so old it might even have been true for some then-still-used Windows systems. By making sure that at least every half-second the events got checked we could keep things in nice order.

The interrupt key thing was (again, so far as I can recall, may be wrong, your smilage may fairy, etc etc) supposed to tickle the relevant semaphore directly and not even pass in a key event. The last time I looked at code in that area made me think that something had been horribly broken but I just didn’t have energy to dig into it.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IIB: Ignore Inquiry and Branch anyway