Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Avoid jamming a thread on blocking push to ringbuffer #30

Open
bmerry opened this issue Oct 14, 2015 · 0 comments
Open

Avoid jamming a thread on blocking push to ringbuffer #30

bmerry opened this issue Oct 14, 2015 · 0 comments
Labels
enhancement

Comments

@bmerry
Copy link
Contributor

bmerry commented Oct 14, 2015

The change to a blocking push on the ringbuffer means that a slow consumer can now jam up an asio thread. Consider changing the push to be asynchronous with asio calling back when the consumer has caught up. This will introduce complexity and possibly reduce performance, so needs to be carefully considered.
bmerry added a commit that referenced this issue Mar 6, 2019
@bmerry
Replace run_in_strand with locking
8bf1348 
run_in_strand lead to issues like #40. The new queue_mutex can still be
a source of similar deadlocks, but heap_ready no longer blocks emplace_reader,
because that uses a separate reader_mutex.

It is still possible for deadlocks to occur when sharing a thread pool
between multiple streams with fewer threads than streams: if it has one
thread, it could be blocked waiting for space in ringbuffer A, which can
prevent a stop on B from making progress. Fixing that would require
addressing #30.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@bmerry