14615 Change in Delay semantics when high priority timer event loop stopped
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. 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
On Wed, Dec 17, 2014 at 4:51 PM, Ben Coman <btc@openinworld.com> 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.
I'd like to change it to (2.), which can be done in a single line.
Your thoughts ?
Which one is going to speed up the headless startup time? Phil
phil@highoctane.be wrote:
On Wed, Dec 17, 2014 at 4:51 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> 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.
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>
Which one is going to speed up the headless startup time?
Phil
Neither will affect it directly. However it might take my interest to look into that after I'm done with my Delay refactorings, so the quicker they get through... ;) (of course, answers should be on a technical basis, not horse trading) So what do you do to convert/run as a headless image? cheers -ben
On Wed, Dec 17, 2014 at 4:51 PM, Ben Coman <btc@openinworld.com> 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 ?
Guillermo Polito wrote:
On Wed, Dec 17, 2014 at 4:51 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> 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>
Ben I would love to be able to answer a clever answer but I'm not deadlock free when it comes with concurrency. I would like igor to answer because he has accumulated experience of concurrent matters. Now I have the impression that I would go for 2 because it opens more doors and that 1 does not really help. Le 17/12/14 16:51, Ben Coman a écrit :
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.
I'd like to change it to (2.), which can be done in a single line.
Your thoughts ?
BTW I **loved** your concerns about concurrency and announcement improving delay Keep pushing Le 17/12/14 16:51, Ben Coman a écrit :
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.
I'd like to change it to (2.), which can be done in a single line.
Your thoughts ?
participants (4)
-
Ben Coman -
Guillermo Polito -
phil＠highoctane.be -
stepharo