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 - 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.


_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171201/0bca281a/attachment.html>