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

[John W. Eaton]

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

I backed out the changeset.  We can probably apply it on default, but first I
want to understand how these two bits of code are equivalent.

Current:


  std::cerr << "warning: broken pipe" << std::endl;

  // Don't loop forever on account of this.
  // FIXME: is this really needed?  Does it do anything
  // useful now?

  if (pipe_handler_error_count++ > 100
      && octave_interrupt_state >= 0)
    octave_interrupt_state++;


Patched:


  std::cerr << "warning: broken pipe" << std::endl;

  // Don't loop forever on account of this.
  // FIXME: is this really needed?  Does it do anything
  // useful now?

  const int curr_pipe_handler_error_count = pipe_handler_error_count++;

  if (curr_pipe_handler_error_count > 100)
    {
      sig_atomic_t curr_interrupt_state
      = octave_interrupt_state.load();

      sig_atomic_t new_interrupt_state;

      do
        new_interrupt_state = curr_interrupt_state + 1;
      while (curr_interrupt_state >= 0 &&
         ! octave_interrupt_state.compare_exchange_weak
         (curr_interrupt_state, new_interrupt_state));
    }


The original intent was to not get stuck continually responding to a long
series of SIGPIPE signals.  If I remember correctly, that was sometimes a
problem long ago when piping output to the pager or to gnuplot.  I don't know
whether it is a real problem now.  Maybe this code could just be removed. 
Keeping it probably does no harm, but the new code should be equivalent to the
old.  I don't understand the do-while part of the new code.  Why is that
needed here?  Previously there was no loop, just a conditional so that the
interrupt_state variable was incremented IF it was already >= 0 (not already
responding to an interrupt) and the pipe error count was > 100 (because we've
seen a long series of SIGPIPE signals).



    _______________________________________________________

Reply to this item at:

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

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