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