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

[Daniel J Sebald]

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.

Dan