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

[John W. Eaton]

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

  It is not safe to use the pthread_cond_signal() function in a signal
  handler that is invoked asynchronously. Even if it were safe, there
  would still be a race between the test of the Boolean
  pthread_cond_wait() that could not be efficiently eliminated.

> One thing I wonder is whether the notion of an exception across threads
> is correct. Unlike threads sharing memory or function calls, signals
> sort of go back to the OS.

I'm not sure what you mean by "whether the notion of an exception
across threads is correct".  I'm fairly sure that the effect of
throwing a C++ exception from one thread and catching it in another is
undefined, but there appears to be a standard way to do this with
C++-11.  But even with that, I'm a bit unsure about calling longjmp
from one thread and what the effect is when the place you want to jump
to is supposed to be running in another thread.

> Long external functions inside separate threads I'm fine with (hey,
> could then maybe make use of multiple cores),

It wouldn't really help us with mulitiple cores.  The main thread
would just be waiting for the long running function to complete, or to
interrupt it if SIGINT is delievered.

> but why if they are run in
> the main thread are they not interruptable by the current mechanism?

Because the signal is (or may be) processed by a different thread, and
we aren't doing the right thing to throw an exception from one thread
to another.

jwe