On Fri, Jun 12, 2015 at 1:00 AM, Thierry Goubier
<thierry.goub...@gmail.com> wrote:
> Hi all,
>
> anybody knows if, when doing something like:
>
> (Delay forMilliseconds: n) wait
>
> It is possible for the Delay to return immediately if n is small enough or
> do we have a guaranteed behavior of at least a 'yield' equivalent?
For sufficiently small values of 'n', there will be no yield behaviour.
To follow the logic (assuming timingPriority > pollingPriority >
userPriority)...
1. Delay>>#wait calls DelayMicrosecondScheduler>>#schedule: (your
pollingPriority process)
2. where "timingSemaphore signal"
3. passes control to #runTimerEventLoop and #handleEventTimer:
(running in the timingPriority process)
4. which invokes #scheduleDelay: to add your delay to /suspendedDelays/
5. back in #handleEventTimer: "Signal any expired delays" cycles
through /suspendedDelays/ such that if 'n' time has passed your
delay's delaySemaphore is immediately signalled, then
6. control returns to #schedule: (your pollingPriority process)
7. and thence to #wait: which does "delaySemaphore wait" -- but this
has already been signalled, so it zooms straight without any chance to
yield.
If you want to ensure yield behaviour I would add the obvious...
Delay>>waitWithYield
self wait.
Processor yield.
However for other sufficiently low values 'n2' (n2>n), not enough
lines of the userPriority process will be executed before your
pollingPriority process takes of, so the UI will effectively be locked
again.
Perhaps what is needed is for your polling process to observe the
/lastCycleTime/ ivar set by WorldState>>interCyclePause: and
dynamically adjust your polling interval to keep lastCycleTime at a
reasonable value.
cheers -ben
> I'm looking into active polling for parallel stuff and I noticed that a busy
> loop with Processor yield may result in more or less locking the vm since it
> only gives scheduling to processes which have a higher or equal priority, so
> this is why I'm looking into using Delay wait instead. But I'd like the
> delay to be as short as possible for performance reason while allowing lower
> priority processes a chance to run.
>
> Thanks,
>
> Thierry
>
>
