[squeak-dev] interrupting a critical: block
btc at openinworld.com
Sat Dec 2 00:10:12 UTC 2017
On 2 December 2017 at 02:00, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Nicolas,
> On Thu, Nov 30, 2017 at 6:18 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>> 2017-12-01 3:07 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>> Hi Nicolas,
>>> On Thu, Nov 30, 2017 at 5:55 PM, Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>> I just had a great success in interrupting a critical: block... Is this
>>>> possibility expected?
>>> Yes. Interrupts are orthogonal to critical sections, including
>>> critical: blocks. The only thing a critical: does is arrange that only one
>>> process can be executing it at any one time. If you want
>>> uninterruptibility you'll want to use valueUninterruptibility.
>> thanks, I was indeed confusing
>> Too bad, the UI is now completely blocked...
>>> (have you tried user interrupt again?)
>> yes without success.
>> So the real issue is what process the user interrupt action should
>>> interrupt. For example, I think it's very wrong that the user interrupt
>>> action can interrupt the finalization process. But which process it
>>> chooses is not well defined. We've discussed this in the past without
>>> coming to much of a conclusion.
>> Without any consideration about implementation, maybe we could base
>> user-interruptability on the Process priority and pray for never forking a
>> runaway high priority.
> I agree. For me the choice of processes and priorities is clear. Any
> runnable process in the range
> Processor userBackgroundPriority to: Processor userInterruptPriority -
> is a candidate for interruption. One question is whether to interrupt the
> currently active one or all processes in that range. That could be
> answered by a preference, or simply based on our existing experience,
> interrupting the highest priority currently running (at the head of its run
> queue) process in that range.
How feasible is it for a heuristic to consider things like...
* % load
* stack depth
* blocked on semaphore
Perhaps a performance monitoring sample could be taken to gather such data
(i.e. change in stack depth over 100ms)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev