|
From: Tim R. <ti...@su...> - 2004-03-18 04:36:05
|
In message <F11...@in...>
Ian Piumarta <ian...@in...> wrote:
> Hmmm. Like primitives 127, 128 and 130, for example?
Excellent choices for discussion.
127 (showdisplayrect for those not able to look it up right now) has a
potentially huge time range. Depends on the size of the rectangle and
what the platform does with it. It invokes (usually) ioShowDisplay and
ioForceDisplayUpdate but might not. The latter does nothing on mac, an
ioProcessEvents on RISC OS, a variety of things on *nix and an
UpdateWindow on win32 if various defer related things are right. It's
_probably_ a good bet that it will take a fairly long time.
128 (arraybecome) is a pretty good bet for averaging a long time.
130 (fullgc) is a certainty on most systems; I'd say that any system
that can fullgc in well under a mS is not going to be worried about an
extra checkForInterrupt.
But we also have the normally very quick Float prims that can trigger a
GC - so some easy detection of a GC could be useful so that it can
trigger a checkForInterrupts. My guess is that it will be rare but we
should be able to cope with it.
[snip]
>
> In those cases, just fall back on setting interruptCheckCounter to zero
> in your ioGetNextEvent() thing. (Like you already do, when the user
> presses the interruptKeyCode, right? ;)
Easy for the things that are already platform specific (interesting
aside on interruptKey though; the event loop in the image is trying to
handle the semaphore itself. Is the vm expected to not signal it
anymore?) but not quite so simple for 'portable' prims IF we want to
try to do optimal checking for the platform. Anything beyond merely
setting interruptCheckCounter to 0 for example.
Well absent any strong suggestions from you guys I'll see what running
with just a zeroing the counter does. I'll even try it on my winXP
laptop if I can find a way to persuade the f^&$%^$ing thing to talk to
the network...(offline advice on settings etc welcomed)
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: BH: Branch and Hang
|