Hi Nicolas,

On Thu, Nov 30, 2017 at 6:18 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:


2017-12-01 3:07 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolas,

On Thu, Nov 30, 2017 at 5:55 PM, Nicolas Cellier <nicolas.cellier.aka.nice@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