Re: interrupt handing and the GUI (bug #37672)

[Michael Goffioul]

On Sun, Nov 10, 2013 at 9:59 PM, Daniel J Sebald <address@hidden> wrote:

On 11/10/2013 03:16 PM, John W. Eaton wrote:

On 11/10/2013 01:25 PM, Daniel J Sebald wrote:

However, periodically checking some variable as regards to an interrupt
signal doesn't feel elegant.

I agree, but I don't see a better way. The pthreads interface allows
for signalling a thread with a "condition variable" but the pthread
documentation explicitly states that calling pthread_cond_signal from
a signal handler is not safe:


http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_signal.html

OK, interesting read.  This is about blocked threads (which isn't the exact scenario) but I see your point about the asynchronous part of it.

On 11/10/2013 03:17 PM, John W. Eaton wrote:

On 11/10/2013 01:44 PM, Daniel J Sebald wrote:

Instead of octave_interrupt_state, maybe there could be two threads in
Octave core: one whose main purpose is to handle signal and thread flow,
the other being the main Octave-core thread as it currently exists.

How does this new thread that handles signals interrupt the other thread?

jwe

What I said probably doesn't make sense after having read the pthreads.

Well, I'll toss out another idea.  From the pthread documentation it sounds like all threads in a process can be set up to handle the same signal, correct?  Before reading this, my (mis)understanding was that there is just one thread that can handle some asynchronous signal coming from the OS.  I'm not quite sure how it would work as I'm not an expert in signal handling, but what if both the Octave core and the GUI had their own signal handler for Cntrl-C and some type of Mutex were used to coordinate signaling behavior.  For example,

1) GUI sets up a mutex so that Octave core (or whatever code indicates a complete calculation) has control of it.

2) GUI launches Octave command.

3) When SIGINT comes to Octave core it does its normal Cntrl-C routine, and when it is complete, somehow that mutex is freed.

4) When SIGINT comes to Octave GUI it

  a) looks to that mutex and waits until it is free under the assumption that Octave core might be doing a little bit of cleanup
  b) when the mutex is free either the GUI does its own cleanup appropriate for a core interrupt (update variables, this or that) assuming it can identify that the Octave-core thread did a break, or it proceeds to do the copy-to-clipboard step if no Octave-core break occurred.

The above seems to assume that multiple signal handlers will be called by the kernel, one in each thread. But I have a different reading of POSIX documentation. Especially "man 7 signal", section "Signal Mask and Pending Signals":

===

A process-directed signal may be delivered to any one of the  threads  that  does  not currently have the signal blocked.  If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.

===

So my understanding is that if you want to get SIGINT to be processed in the octave thread, the GUI thread must block the signal using pthread_sigmask.

Michael.