On Fri, Dec 01, 2017 at 03:18:44AM +0100, Nicolas Cellier 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 do recall discussion this on various occasions, see http://bugs.squeak.org/view.php?id=1041
A key point is Andreas Raab's four tests for interruptability:
"[true] whileTrue" "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" "Smalltalk createStackOverflow" "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"
As long as those four things are interruptable, the overall interrupt behavior is at least reasonable, if not perfect.
At present, there is no guarantee that you will not sometimes interrupt the finalization process or some other process completely unrelated to the thing that is actually causing your problem.
Dave