It's difficult to handle a timeout from rs2::pipeline::wait_for_frames

[ranrav]

---

Required Info
Camera Model	D435
Firmware Version	(issue not related to specific device)
Operating System & Version	MacOS
Platform	Macbook Pro
SDK Version	2.2.12.0 }
Language	C++
Segment	Others

I'm trying to use the rs2::pipeline framework in my app.

It seems like the most suitable way to use it without blocking any UI is to have a dedicated thread that calls the pipeline::wait_for_frames in a loop.

I don't want to use the default timeout of 5 seconds because I don't want the thread to block for that much time. I'd like the app to be able to set a flag which will cause the loop to exit and the thread to terminate cleanly, and waiting 5 seconds for the loop to exit is too much.

So timeouts are pretty frequent, which is fine.

The problem is, when frames are not available within the allowed time, the RealSense2 SDK is throwing a std::runtime_error object with an error message saying the frame didn't arrive in time.

This timeout indication is both awkward to detect and expensive in runtime.

Would it be possible to add a function that looks something like:
bool try_wait_for_frames(int milliseconds)

So that when a timeout occurs a false value would be returned instead of an exception being thrown? Returning false seems to be a very common way for many APIs to indicate the waiting function returned because of a timeout.

While on that note, is there a better way to continuously pull frames without a busy loop? What I'm aiming for is any kind of asynchronous programming model that would utilize completion ports and invoke the user's callback when frames are ready, instead of blocking the thread.

Thanks

[dorodnic]

Hi @ranrav
Thank you for the feedback, we agree with what you are saying and a fix is already on the way (you can follow #1844 and #1730 for more information)

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment]
@ranrav,
The feature has been implemented and merged into development branch, please refer to the PR attached :
#2055

Please let me know if this solves your issue, thank you.

[dorodnic]

Suggested new API is now part of 2.14.0