Recently there were some problems with Delays being missed when long running
primitives were used. The current workaround is to check the tick at the
beginning of #primitiveResponse: and then to see if the prim took longer thn
one tick at the end of #primitiveResponse.
The _bad_ part of this is that the check is done for _every_ primitive
(assuming a Delay is in progress, of course) even though most primitives are
known to be very quick.
I have an alternative suggestion that might help, but would require minor
rewriting of a few dozen prims. If the tick-checking is removed from
#primtiveResponse and added to those few prims that can run  a long time, I
suspect that the overall performance would be quite a lot better. Without
having exhaustively worked this through yet, I think that simply adding a 'self
checkTimerSituation' to the end of the long-running prims would do. Since this
would obviously be run much less often than the current timer checking, the
optimisation of using cheap, low-res timers would probably be unneccessary.
For plugin external prims, I guess the simplest answer is to do the check as
part of the external call, since many plugin prims are for long running
activities.
Does anyone see any major hole in the theory? I don't have time right now to
try it out, but any who can handle building a VM could do it pretty trivially.

tim

-- 
Strange OpCodes: QVC: Question Valid Command
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>