On Sun, Nov 10, 2013 at 9:59 PM, Daniel J Sebald <address@hidden
<mailto: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
<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.