On Wed, Dec 17, 2014 at 4:51 PM, Ben Coman <[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. 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? > > 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?14353 > >
