[squeak-dev] interrupting a critical: block
eliot.miranda at gmail.com
Fri Dec 1 18:00:18 UTC 2017
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 - 1
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev