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