Smalltalk › Squeak › Squeak - Dev

interrupting a critical: block

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Nicolas Cellier

interrupting a critical: block

I just had a great success in interrupting a critical: block... Is this possibility expected?

Too bad, the UI is now completely blocked...

=?UTF-8?B?Q2FwdHVyZSBk4oCZZcyBY3JhbiAyMDE3LTEyLTAxIGHMgCAwMi41Mi40Ni5wbmc=?= (91K) Download Attachment

Eliot Miranda-2

Re: interrupting a critical: block

Hi Nicolas,

On Thu, Nov 30, 2017 at 5:55 PM, Nicolas Cellier <[hidden email]> 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

Nicolas Cellier

Re: interrupting a critical: block

2017-12-01 3:07 GMT+01:00 Eliot Miranda <[hidden email]>:

Hi Nicolas,

On Thu, Nov 30, 2017 at 5:55 PM, Nicolas Cellier <[hidden email]> 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

David T. Lewis

Re: interrupting a critical: block

On Fri, Dec 01, 2017 at 03:18:44AM +0100, Nicolas Cellier wrote:

> 2017-12-01 3:07 GMT+01:00 Eliot Miranda <[hidden email]>:
>
> > Hi Nicolas,
> >
> > On Thu, Nov 30, 2017 at 5:55 PM, Nicolas Cellier <
> > [hidden email]> 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

Denis Kudriashov

Re: interrupting a critical: block

In reply to this post by Nicolas Cellier

Hi Nicolas.

2017-12-01 2:55 GMT+01:00 Nicolas Cellier <[hidden email]>:

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

Nicolas Cellier

Re: interrupting a critical: block

2017-12-01 9:32 GMT+01:00 Denis Kudriashov <[hidden email]>:

Hi Nicolas.

2017-12-01 2:55 GMT+01:00 Nicolas Cellier <[hidden email]>:
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...

Eliot Miranda-2

Re: interrupting a critical: block

In reply to this post by Nicolas Cellier

Hi Nicolas,

On Thu, Nov 30, 2017 at 6:18 PM, Nicolas Cellier <[hidden email]> wrote:

2017-12-01 3:07 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolas,

On Thu, Nov 30, 2017 at 5:55 PM, Nicolas Cellier <[hidden email]> 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

timrowledge

Re: interrupting a critical: block

>
> 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; [hidden email]; http://www.rowledge.org/tim
Foolproof operation: All parameters are hard coded.

Ben Coman

Re: interrupting a critical: block

In reply to this post by Eliot Miranda-2

On 2 December 2017 at 02:00, Eliot Miranda <[hidden email]> wrote:

Hi Nicolas,

On Thu, Nov 30, 2017 at 6:18 PM, Nicolas Cellier <[hidden email]> wrote:

2017-12-01 3:07 GMT+01:00 Eliot Miranda <[hidden email]>:
Hi Nicolas,

On Thu, Nov 30, 2017 at 5:55 PM, Nicolas Cellier <[hidden email]> 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