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

Communication protocols' auto-closure #7

Open
Terae opened this issue Nov 20, 2018 · 0 comments
Open

Communication protocols' auto-closure #7

Terae opened this issue Nov 20, 2018 · 0 comments
Assignees
Labels
enhancement New feature or request medium priority

Comments

@Terae
Copy link
Member

Terae commented Nov 20, 2018

Is your feature request related to a problem? Please describe.
Actually, when we call the recv_frame(const atomic_bool&, function<void(GlobalFrame)> function from a Protocol, the reception is closed when the running_execution: atomic_bool& flag is set to false.

However, the underlying called recv_frame function is still blocking so the library's user needs to send a frame (even empty) to go out of the receiving function and so stop the receiver thread.

Describe the solution you'd like
All the receiving process should be hidden for the user and so the only called to running_execution.exchange(false) should properly close all communication threads, without to use the client.send_frame({}); hack.

Describe alternatives you've considered
This functionality would be implemented inside the AbstractSerialProtocol::recv_frame() function: at the end of the while(runnin_execution) {...} loop, we could call a killer handler implemented in each protocol as a function<void(void)> signatured function.

It could also be done by using a shared_ptr<AbstractSerialProtocol> _killer_client, in the case we can interrupt all protocols by only sending an empty frame on this client.

@Terae Terae self-assigned this Nov 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request medium priority
Projects
None yet
Development

No branches or pull requests

1 participant