-
-
Notifications
You must be signed in to change notification settings - Fork 70
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
zcm handle with timeout #380
Comments
This kinda goes against the "blocking" vs "nonblocking" transport API. We can, of course, adjust the API, but I would be hesitant to do so |
Yeah I realize that. I think it might even be as easy as allowing handle_nonblock to be called even on a blocking transport. Currently, it just asserts if you try to do that, even though there's nothing stopping blocking.cpp from effectively doing a handle_nonblock (ie check to see if there's a message available, then either dispatch it or return E_AGAIN). I think I would be ok with that API update. |
There's no api to "check" if there's a message available as far as I'm aware. On a blocking transport, that check blocks |
Not from the transport, but luckily that's not what it actually needs to check. It just needs to check if the threadsafe_queue recvQueue has a message sitting in it. Currently, handle just blocks until the queue has a message (rather than check if it has a message). |
Current implementation has "handle" block until a message is received or published. Running into some scenarios where this behavior is undesirable, and it'd be nice if there was a way to pass a maximum time to the function before it would return E_AGAIN.
The text was updated successfully, but these errors were encountered: