Conversation
|
This PR has not comments anywhere, no explanation/motivation, and doesn't seem very well planned. I would prefer the other PR over this one. Thanks though. |
|
There is also #55 for the same topic. |
Yes, did look into to that originally. This pr solves the 0 timeout case, which is actually 0 compared to actually waiting for the event object where typical deviation is 4-20ms (when timeout > 0 there is is race between event object and timeout signal which is fine, though I guess if we want to rely on event object mostly then it could be so that if timeout > 0 then INFINITE is passed etc.), also somewhat cosmetic things related to handling event object(s) how it is normally done. My personal motivation would be to add later on cancellable rx event or eq. for streaming use case. |
|
After some thinking, I guess the most sense would make to disable the timeouts with setcommtimeouts, and only rely on wait timeout. Though one caveat remains if someone sets the timeout without setting the internal timeout, in that case only problem would be if internal timeout is lower than the set comm timeout one, then the timeout would be less than expected. |
No description provided.