Hi John -

The rational of this change is to ensure that when you force an interrupt check that we query for i/o events as well since the effect of the interrupt change might be related to i/o. The case in question was sockets: Without that change, ioProcessEvents would only be called every 200ms if the VM is in a busy loop which limits latency to 200ms in a case like this:

socket connectTo: addr port: port. [socket isConnected] whileFalse.

(this is a bit unrealistic example but there are many realistic ones)

In order to overcome the latency issue we need to both, signal the VM that something has happened (we do this via forceInterruptCheck) but we also need to make sure we look at ioProcessEvents ASAP, which is why the nextPollTick is being reset. This brings the latency down to (effectively) nothing as illustrated in the Croquet VM tests.

Note that these changes will likely have *dramatic* positive impacts for systems running on servers under heavy computational load. Many of the oddities reported on Unix systems can likely be traced to this very problem.

Cheers, - Andreas

John M McIntosh wrote:

This is a bit uclear, all this is doing is forcing a call to ioProcessEvents()

This assumes ioProcessEvents() is doing something interesting that you want it to do... which is?

Hint on the mac all it does is check to see if the screen bits should be flush (every 20ms) , and snatch any pending UI events (every 16ms). Nothing else. So what else should it be doing?

On 17-Apr-06, at 10:33 AM, Ian Piumarta wrote:

...

Please integrate immediately, unless the same change already reached the Squeak VMM by way of the Croquet VMM.

'From Croquet1.0beta of 11 April 2006 [latest update: #0] on 17 April 2006 at 10:29:39 am'! "Change Set: Socket-latencyFix-ikp Date: 14 April 2006 Author: Ian Piumarta

Reset nextPollTick to zero in forceInterruptCheck so that asynchronous external i/o can obtain an immediate ioProcessEvents."!

!Interpreter methodsFor: 'processes' stamp: 'ikp 4/14/2006 16:30'! forceInterruptCheck "force an interrupt check ASAP" interruptCheckCounter := -1000. nextPollTick := 0! !

--

John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Whilst I can appreciate the value of adding the nextPollTick reset as a way of getting soon-as-possible response from the plain old checkForInterrups code, I feel sure there was a more sophisticated technique that was discussed many (many, many) moons ago. August '00 or thereabouts seems to be when most of the email flopped around.

Trouble is I can't spot an actual email with any sensible seeming details in it, so maybe it was something discussed in person or by phone. Does anyone else recall a possible technique from back then?

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim All programmers are playwrights and all computers are lousy actors.