Ao Xu authored 4 years ago and Marco Clemencic committed 4 years ago

an alternative of `InputCopyStream` that does not use BeginEvent.

Re-apply !1064: Isolate sub-slot data from the parent slot

See merge request !1095

Protect messages in event loop

See merge request !1100

This reverts merge request !1079

Update versions for v33r2

See merge request !1083

Fixes for ROOT master

See merge request !1071

Use fmtlib instead of boost::format (where possible)

Closes #112

See merge request gaudi/Gaudi!1046

Conditions alg test, with stall debug info

See merge request !1092

see https://sft.its.cern.ch/jira/browse/ROOT-10771

Make sure the TES is cleaned by EventLoopMgr before finalize

Closes LHCBPS-1850

See merge request !1082

Fix race condition between tests

See merge request !1074

Fix propagation of StopIteration exception

Closes #129

See merge request !1093

Update HiveDataBroker to use C++20 ranges if available.

See merge request !1089

Scott Snyder authored 4 years ago and Marco Clemencic committed 4 years ago

gcc 10 in C++20 mode gives errors on the range-v3 code in HiveDataBroker.cpp.
However, gcc 10 has C++20 ranges, so switch to using that implementation
instead if it is available.  In so doing, we need to change remove_if
to filter, as the former isn't in C++20 ranges.

Fixes for c++20

See merge request !1085

Scott Snyder authored 4 years ago and Marco Clemencic committed 4 years ago

  - Three-way comparison.
  - Typedefs removed from std::allocator

Fix thread-safety problem in GaudiHandle

See merge request !1084

Scott Snyder authored 4 years ago and Marco Clemencic committed 4 years ago

The component retrieval code in GaudiHandle can lead to operator->()
returning a null pointer for a valid handle, if it is called
simultaneously from multiple threads.

The relevant code in GaudiHandle is:

```
  T* operator->() {
    assertObject();
    return m_pObject;
  }

  void assertObject() const {
    if ( UNLIKELY( !isValid() ) ) {
       throw GaudiException ...
    }
  }

  bool isValid() const {
    // not really const, because it may update m_pObject
    return m_pObject || retrieve().isSuccess();
  }

  StatusCode retrieve() const {
    // not really const, because it updates m_pObject
    StatusCode sc = StatusCode::SUCCESS;
    if ( m_pObject && release().isFailure() ) { sc = StatusCode::FAILURE; }
    if ( sc && retrieve( m_pObject ).isFailure() ) {
      m_pObject = nullptr;
      sc        = StatusCode::FAILURE;
    }
    return sc;
  }
```

Note that if the pointer is already set when retrieve() is called, it
clears it and redoes the lookup.

So we could have:

```
  thread 1 calls operator->.  m_pObject is not set, so it executes
  through to retrieve() after the test on m_pObject.

  thread 2 calls operator->.  m_pObject is not set, so it executes
  through to the start of retrieve().

  thread 1 continues, does the lookup, sets m_pObject and returns.

  thread 2 continues, tests m_pObject, finds it set, and calls reset()
  to clear it.

  thread 1 continues, returning through operator->.  m_pObject is now
  null, so it returns null.

  thread 2 continues with the retrieve, and returns a valid pointer
  from operator->.
  ```

I've tentatively tried to fix this by making m_pObject atomic, and
changing retrieve() so that it will not change m_pObject if it is
already set.  I think that's consistent with what's implied
by retrieve() being const.  ATLAS software seems fine with this change,
but this is, however, a potential change of behavior, so i point
it out here.

Misc. Sanitiser improvements

See merge request !1081

make GaudiHandleArray.__str__ consistent with GaudiHandle.__str__

See merge request !1070

Fix trivial typo in message.

See merge request !1087