[Octave-bug-tracker] [bug #61370] gcc's thread sanitizer reports several race conditions

[anonymous]

Follow-up Comment #7, bug #61370 (project octave):

Dear John W. Eaton,

sig_atomic_t is atomic just for normal signal handlers (e.g. using the signal
function), but not for concurrent threads. In case of octave, the signal
handler is executed in a concurrent thread. See the code below:
 

  if (pthread_create (&sighandler_thread_id, 0, signal_watcher, handler))
    {
      // FIXME: what else should we do?
      abort ();
    }



static void *
signal_watcher (void *arg)
{
 ...

  while (1)
    {
      int sig_caught;

      if (sigwait (async_signals, &sig_caught))
        {
          abort ();
        }

      (*handler) (sig_caught);
    }
}


But of course, octave_interrupt_state could be declared as std::atomic<int> as
well.

[comment #5 comment #5:]
> Most of this proposed change seems OK to me except I find the declaration
> 
> 
> std::atomic<sig_atomic_t> octave_interrupt_state;
> 
> 
> to be a bit strange since I thought sig_atomic_t was already supposed to be
an atomic type.
> 
> More importantly, the proposed change moves the octave_interrupt_state
variable inside an #if defined (__cplusplus) / #endif block so that it is no
longer declared for C programs.  The original intent was to allow quit.h to be
included in C or C++ source files and for some of the symbols it declares to
be available in C source files.  I'm not sure how important this feature
really is, but is it necessary to prevent octave_interrupt_state from being
available in C source files?
> 
> If we do decide that octave_interrupt_state only needs to be available in
C++ source files, then I think we can just declare it as std::atomic<int>
instead of std::atomic<sig_atomic_t>.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61370>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/