I just had a great success in interrupting a critical: block... Is this possibility expected? Too bad, the UI is now completely blocked...
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.
Too bad, the UI is now completely blocked...
(have you tried user interrupt again?)
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.
_,,,^..^,,,_ best, Eliot
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.
_,,,^..^,,,_ best, Eliot
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
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
So the real issue is what process the user interrupt action should interrupt.
Are we able to present some UI to choose? It could certainly be a bit tricky, but very useful.
Clearly there’s some interesting issues with timing - we couldn’t leave everything running while a normal UI is built, presented and the user chooses since some of our interruptions are attempts to stop a runaway recursion or memory flood. Might a very high priority process that uses bare minimum code to display a list of processes and watches for a mouse/keyboard event work? In principle we can even do it in another host window (remember them?) to avoid disturbing the ‘real’ display.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Foolproof operation: All parameters are hard coded.
On 2 December 2017 at 02:00, Eliot Miranda eliot.miranda@gmail.com wrote:
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.
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)
cheers -ben
Hi Nicolas.
2017-12-01 2:55 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
I just had a great success in interrupting a critical: block... Is this possibility expected?
It is definitely needed because in case of deadlock it is the only way to repair the image.
Too bad, the UI is now completely blocked...
2017-12-01 9:32 GMT+01:00 Denis Kudriashov dionisiydk@gmail.com:
Hi Nicolas.
2017-12-01 2:55 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:
I just had a great success in interrupting a critical: block... Is this possibility expected?
It is definitely needed because in case of deadlock it is the only way to repair the image.
Yes, my bad, critical: is about mutual exclusion as Eliot already reminded me. Having the image unresponsive and a stack saying critical: raised my suspiscion.
Too bad, the UI is now completely blocked...
squeak-dev@lists.squeakfoundation.org
-
Ben Coman -
David T. Lewis -
Denis Kudriashov -
Eliot Miranda -
Nicolas Cellier -
tim Rowledge