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.

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

Massive deadlocking when disconnecting connections in parallel #300

Open
doudou opened this issue Jun 14, 2019 · 2 comments
Open

Massive deadlocking when disconnecting connections in parallel #300

doudou opened this issue Jun 14, 2019 · 2 comments
Labels
Milestone

Comments

@doudou
Copy link
Contributor

doudou commented Jun 14, 2019

The refactored channel implementation that just landed in master has a very liberal use of locking, which leads to deadlocks when doing parallel disconnections. I'm chasing those, and will propose a PR for review, I'm opening this issue to track the problem.

Generally speaking, one major issue I see (apart from the deadlocking) is that remote disconnection calls are done under lock. My current strategy is to split the "remove channel from channel list(s)" from the "destroy the channel".

@meyerj
Copy link
Member

meyerj commented Jun 14, 2019

Thanks for reporting. Could you already share an example or unit test to reproduce the problem?

There is a set of new test cases in ports_test.cpp, introduced in f1404ff, that should have covered issues with parallel port connection, disconnection, reads and writes. But indeed it only spawns a single thread to add and remove an input port from the connection and another for an output port, but never two input or output ports concurrently.

What you suggest sounds a bit like (partially) reverting #283, a patch that was only added recently. Without, the test cases in ports_test.cpp mentioned above did not check whether the port connections were actually successful, which was often not the case.

@doudou
Copy link
Contributor Author

doudou commented Jun 17, 2019

See #302

doudou added a commit to rock-core/package_set that referenced this issue May 5, 2020
The goal is not to "fork" per-se, but
orocos-toolchain/rtt#300 makes it
impossible to use it (and I don't have the time to track it
without the help of the Intermodalics guys who wrote it in
the first place).

Since I now get some to track and fix some bugs ... Fork
it is :(
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants