[proost]

Fixes #4532

Changes

Using conditional variable, return early even if background thread is not joined.

This is half solution for only Shutdown.

limitation: current destructor call InternalShutdown without timeout. So if exporter Export runs indefinitely, then destructor never finished. This is same after this PR is merged.

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.64%. Comparing base (d05c6a8) to head (4e08f27).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4767      +/-   ##
==========================================
+ Coverage   86.61%   86.64%   +0.04%     
==========================================
  Files         530      530              
  Lines       21169    21181      +12     
==========================================
+ Hits        18333    18350      +17     
+ Misses       2836     2831       -5     

Files with missing lines	Coverage Δ
...ude/opentelemetry/sdk/trace/batch_span_processor.h	100.00% <ø> (ø)
sdk/src/trace/batch_span_processor.cc	94.48% <100.00%> (+3.03%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mateenali66]

Thanks for the patch.

The timeout works, and batch_span_processor_test is clean under TSan at 4e337fe7.

BatchLogRecordProcessor::InternalShutdown has the same untimed join() (batch_log_record_processor.cc:410), and #4532 names both, so please use "Part of #4532" in the description.

See comments about what the caller still waits for, and the Shutdown contract.

[mateenali66]

Thanks for the update.

The repeated Shutdown now matches the contract, and batch_span_processor_test passes plain and under TSan at 4e08f27d.

The Part of #4532 request is still open, since BatchLogRecordProcessor::InternalShutdown keeps the untimed join().

See comment about a crash when Shutdown overlaps teardown.

Will approve once comments are fixed.

[mateenali66]

This join() can run while another thread is still inside the join() in InternalShutdown, and std::thread::join then throws from a destructor.

With shutdown_m no longer taken, a second Shutdown returns before the first has finished, so its caller can release the last reference.

thread A  provider->Shutdown()
thread B  provider->Shutdown(200ms), then release the last reference

macOS, 12 runs each
main      B returns at +3003 ms, 12 clean
head      B returns at +55 ms, 12 abort
          thread::join failed: Invalid argument

Please take shutdown_m again, after the exchange in InternalShutdown and before this joinable().

std::lock_guard<std::mutex> shutdown_guard{synchronization_data_->shutdown_m};

Tested with both, B still returns at +55 ms, 12 clean, and the suite passes TSan over 20 repeats.