You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
chunk_stream_group::emplace_back starts like this:
std::lock_guard<std::mutex> lock(mutex);
if (chunks.get_tail_chunk() != 0 || last_flush_until != 0)
{
throwstd::runtime_error("Cannot add a stream after group has started receiving data");
}
However, when I accidentally added readers to streams before all the streams were added, I didn't get the exception, but instead deadlocked trying to obtain the lock. There needs to be a better way to detect this condition. Possibly when the first data arrives, it can set an atomic flag, which emplace_back checks before taking the lock. This is still racy, but the whole thing is fundamentally racy anyway since it depends on the timing of the data arriving.
The text was updated successfully, but these errors were encountered:
bmerry
added a commit
to ska-sa/katgpucbf
that referenced
this issue
Feb 13, 2024
It was adding new streams to the stream group after allowing data to
flow, which is a no-no. It's not supposed to deadlock, but I've opened
ska-sa/spead2#314 for that.
chunk_stream_group::emplace_back
starts like this:However, when I accidentally added readers to streams before all the streams were added, I didn't get the exception, but instead deadlocked trying to obtain the lock. There needs to be a better way to detect this condition. Possibly when the first data arrives, it can set an atomic flag, which
emplace_back
checks before taking the lock. This is still racy, but the whole thing is fundamentally racy anyway since it depends on the timing of the data arriving.The text was updated successfully, but these errors were encountered: