Behavior of Ctrl+C with respect to unwind_protect_cleanup blocks

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Behavior of Ctrl+C with respect to unwind_protect_cleanup blocks

Rik-4
Maintainers,

Between versions 4.0 and 4.2 the behavior of unwind_protect blocks with
respect to Ctrl+C interrupts changed.  Previously, an interrupt was treated
the same as an error and the unwind_protect_cleanup block was executed.
Now, the interrupt is immediate and returns control to the command prompt
without taking any other actions.

The issue was reported here: https://savannah.gnu.org/bugs/?51209e.  Sample
code is

unwind_protect
  while (1)
  endwhile
unwind_protect_cleanup
  disp ("executing cleanup");
end_unwind_protect

This is partly a philosophical question.  Should Ctrl+C be an immediate
escape path from all code including cleanup blocks that might result in
further hangs?  In another analogy, should it be treated like a
non-maskable interrupt?  Or should Ctrl+C be treated more like an IPC
signal indicating that the user would like control back as soon as is
reasonably possible?

The issue currently is that the behavior changed without anyone making an
explicit decision about this.  Currently there is m-file code that uses the
second interpretation.  For example, ginput.m uses it to restore callbacks
on the figure window.  If Ctrl+C is used then the figure can be left in a
mixed-up state.

--Rik


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Behavior of Ctrl+C with respect to unwind_protect_cleanup blocks

John W. Eaton
Administrator
On 06/10/2017 09:33 AM, Rik wrote:

> Between versions 4.0 and 4.2 the behavior of unwind_protect blocks with
> respect to Ctrl+C interrupts changed.  Previously, an interrupt was treated
> the same as an error and the unwind_protect_cleanup block was executed.
> Now, the interrupt is immediate and returns control to the command prompt
> without taking any other actions.

I don't think any change like that was intentional.  Do we know what
changeset is responsible?

Is the behavior different for onCleanup objects?  I think they should
behave similarly, and both should run the cleanup actions on interrupt.
They are intended to run those actions no matter how execution leaves
the block (or scope).

jwe


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Behavior of Ctrl+C with respect to unwind_protect_cleanup blocks

Rik-4
On 06/10/2017 07:04 AM, John W. Eaton wrote:

> On 06/10/2017 09:33 AM, Rik wrote:
>
>> Between versions 4.0 and 4.2 the behavior of unwind_protect blocks with
>> respect to Ctrl+C interrupts changed.  Previously, an interrupt was treated
>> the same as an error and the unwind_protect_cleanup block was executed.
>> Now, the interrupt is immediate and returns control to the command prompt
>> without taking any other actions.
>
> I don't think any change like that was intentional.  Do we know what
> changeset is responsible?

No, but I'll try bisecting.

>
> Is the behavior different for onCleanup objects?  I think they should
> behave similarly, and both should run the cleanup actions on interrupt.
> They are intended to run those actions no matter how execution leaves the
> block (or scope).

onCleanup seems to work.  I used the following m-file

function tst_onclean ()
  x = onCleanup (@() disp ('hello'));
  while (1)
  endwhile
endfunction


When I execute 'tst_onclean' and do a Ctrl+C then "hello" is printed.

--Rik
>
> jwe
>
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Behavior of Ctrl+C with respect to unwind_protect_cleanup blocks

Rik-4
In reply to this post by John W. Eaton
On 06/10/2017 07:04 AM, John W. Eaton wrote:

> On 06/10/2017 09:33 AM, Rik wrote:
>
>> Between versions 4.0 and 4.2 the behavior of unwind_protect blocks with
>> respect to Ctrl+C interrupts changed.  Previously, an interrupt was treated
>> the same as an error and the unwind_protect_cleanup block was executed.
>> Now, the interrupt is immediate and returns control to the command prompt
>> without taking any other actions.
>
> I don't think any change like that was intentional.  Do we know what
> changeset is responsible?

Bisecting, as usual, was not as straightforward as it should have been.
However, I did finally locate the responsible changeset.

parent: 20651:b70cc4bd8109
 begin removal of global error_state variable

--Rik

Loading...