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 ?
https://pharo.fogbugz.com/default.asp?14615
https://pharo.fogbugz.com/default.asp?14353
