Interpreter change

[Ian Piumarta]

On Apr 17, 2006, at 2:30 PM, John M McIntosh wrote:

> For some reason lost in time, it's called only in
>
> ioGetNextEvent()
>
> I do think here if you want a specialized call to process socket  
> events what about a flag aioPollNeeded and set that to true, then  
> check for that in checkForInterrupts()

One obvious condition would be to set the flag when external  
semaphores are registered.  That might be messier than just resetting  
nextPollTick.

> Otherwise  you end up with ioProcessEvents() being called say oh  
> 10,000 a second if there are lots of socket events happening? and  
> just because ioProcessEvents() handles
> sockets doesn't mean it might be doing other things which are  
> assuming a low calling rate.

The question is how to separate things the image/Interpreter know  
most about from things the support knows most about, and keeping the  
assumptions between them as simple as possible.

If the support is doing some expensive operation in ioProcessEvents,  
maybe the support should arrange to limit the frequency of these  
operations rather than trying to communicate something back to the  
Interpreter to affect the frequency indirectly.  OTOH, assuming that  
ioProcessEvents is either (1) expensive or (2) not performing a time- 
critical poll of activity (in the absence of any other easy means to  
perform such a poll) is also a bad mistake on the part of the  
Interpreter.

Arranging for forceInterruptCheck to cause an ioProcessEvents at the  
earliest opportunity seems to me to make the fewest assumptions  
across the Interperter/support barrier.  The support code knows what  
it's doing in calling forceIntrCheck, and can take steps to  
compensate for the frequency of ioProcessEvents if necessary.  (The  
nextPollTick logic would, I suspect, be far better in ioProcessEvents  
than in checkForInterrupts.)

If you have a simpler solution I'd be eager to hear it.

Cheers,
Ian