John M McIntosh
johnmci at smalltalkconsulting.com
Mon Apr 17 22:06:17 UTC 2006
On 17-Apr-06, at 2:53 PM, Ian Piumarta wrote:
>> 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.
ioProcessEvents had an implied expense which is why it was only
checked every 500 ms, or what ever.
What I'd suggest here is setting a aioPollNeed flag
have forceaioPoll() that does
set the aioPollNeed flag
check aioPollNeed, if true call aioPoll() and reset.
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Vm-dev