Guillermo Polito wrote:
On Wed, Dec 17, 2014 at 4:51 PM, Ben Coman <[email protected]
<mailto:[email protected]>> wrote:
I'm looking for some community feedback on Case 14615. When the high
priority Delay timer event loop is stopped, there are two basic choices:
1. Delays wait indefinitely, since their delaySemaphore is never
signaled, and so for example, the UI locks up.
2. Delays are ignored, proceeding immediately. This would let the UI
continue working, give you a chance to restart the timer event loop,
or change the DelayScheduler algorithm on-the-fly (e.g. mutex,
semaphore, spinlock).
The system currently does (1.). This is impeding integration of
Case 14252 to change Delays from millisecond to microsecond clock,
since as a Preload the Delay timer event loop is stopped to load the
slice.
Did you try to do the switch in another process?
[
oldDelayLoop stop.
newDelayLoop start.
] forkAt: Processor highestPriority.
> That should do that outside of the UI event loop, and so the new delay
> process installation will not be suspended forever.
>
That could be a useful approach, except for the current purpose we need
to do...
oldDelayLoop stop.
"User operation of the UI to use the Integration tool"
newDelayLoop start.
btw, Another reason to avoid a stopped delay loop freezing the UI (as
proposed) is that you then can't debug a broken delay loop (which has
been important to me to develop these changes).
Also, is there any kind of migration from the old delays to the new
delay process? Or they are shared and as soon as the new delay loop
starts it handles the old delays?
Even though I said change timer event loop "on-the-fly", I don't expect
it will be a frequent activity. Stopping the timer event loop currently
signals all suspended delays to clear them, to guarantee no stuck
delays. The supposition being that... one reason to stop the event loop
is if something goes wrong and you need to start it fresh, this should
be done without carrying forward old data that may be problematic.
Now if you require the delays to be transfered to the newDelayLoop, that
facility could be added.
For the particular case changing from millisecond to microsecond clock,
sharing the delays is problematic since the instance variable holding
the delayDuration has significantly changed magnitude. Working on a some
kind of migration strategy was more work than was necessary.
Thanks for you feedback.
I'd like to change it to (2.), which can be done in a single line.
Your thoughts ?
https://pharo.fogbugz.com/__default.asp?14615
<https://pharo.fogbugz.com/default.asp?14615>
https://pharo.fogbugz.com/__default.asp?14353
<https://pharo.fogbugz.com/default.asp?14353>
