Re: ctrl-c and oct files

[John W. Eaton]

On 04/30/2018 08:04 PM, John Donoghue wrote:
> Further more, if I try something such as:
>
> #include <octave/oct.h>
> #include <octave/sighandlers.h>
>
> #include <unistd.h>
>
> void catch_ctrl(int sig)
> {
>    printf("catch here %d\n", sig);
> }
>
> DEFUN_DLD (testctrl, args, nargout, "Test Ctrl-C")
> {
>    printf("starting sleep\n");
>
>    auto old_handler = octave::set_signal_handler(SIGINT, catch_ctrl);
>
>    sleep(10);
>
>    octave::set_signal_handler(SIGINT, old_handler);
>
>    printf("finished sleep\n");
>
>    return octave_value();
> }
>
>
> and press ctrl-c, catch_ctrl never displays anything.
>
>
> > #include <octave/oct.h>
> > #include <unistd.h>
> >
> > DEFUN_DLD (testctrl, args, nargout, "Test Ctrl-C")
> > {
> >   printf("starting sleep\n");
> >
> >   BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
> >
> >   sleep(10);
> >
> >   END_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
> >
> >   printf("finished sleep\n");
> >   return octave_value();
> > }
> >
> > Build with mkoctfile, in fedora 26, with octave 4.3.92, hg 
> > 25327:abc5095d58c2
> >
> >
> > Running it with octave --no-gui, when I run testctrl, and press ctrl-c 
> > after a second, shouldn't the code break out?
> >
> > Currently, for me, ctrl-c doesnt appear to do anything - the prints 
> > execute after the 10 second sleep, rather than breaking out part way 
> > through the sleep.
> >
> > octave --gui does the same.

The BEGIN_INTERRUPT_IMMEDIATELY... no longer does anything except 
introduce a new scope, and SIGINT is now blocked in all threads except 
one signal handling thread.  The signal mask of the Octave interpreter 
thread is inherited by subprocesses.  So the interrupt is never 
delivered to your subprocess.  This change was made to fix the problem 
of Octave randomly crashing in threads started by openblas (for example).

I'm not sure how best to manage this situation and allow .oct file 
functions to be interrupted unless they somehow check for interrupts.

If you umask SIGINT in your function, then there is no guarantee that a 
SIGINT signal will be delivered to your function or the separate signal 
handling thread that Octave creates.

What you can do is periodically check the interpreter's interrupt state 
and throw an exception, the same as the rest of Octave does.  But that 
obviously doesn't allow functions like sleep to be interrupted.  That's 
why we made Octave's sleep function loop over smaller intervals with 
checks for the interrupt state between the calls to the system sleep 
function.

Another option is to run the .oct file function in a separate thread and 
have the parent thread check the interrupt state and cancel the .oct 
file sub thread if an interrupt is detected.  Maybe we could change 
Octave to do this job, but it seems like a lot of overhead to be 
creating a separate thread each time a .oct file function is called.

Is there another better way?

jwe