Frequently Asked Question
Linux blocking calls and signals in the streaming thread
Last Updated 2 years ago
In Linux, user should not use blocking calls and blocking operations (such as reading std::cin) in the same thread, which is subscribed to signals, i.e. in the thread where KYFG_Open() function was called.
There are two possible solutions to overcome this:
The 1st approach is preferred over the 2nd one because using. KYFGLIB_CONCURRENCY_SA_RESTART may impact stream performance in certain circumstances. This is because what this flag usually means is that your blocking thread will still be interrupted by a signal, but the operating system will just save that thread state, switch context to signal handling procedure and then restore the context to proceed with the blocking call.
There are two possible solutions to overcome this:
- Use different threads for KYFG_Open() and std::in, as well as for any other blocking operations such as reading/writing files, etc.
- Use KYFGLib_Initialize() function, described in "Vision Point API Data Book" document, before opening any Frame Grabber, cameras and starting streams, and add KYFGLIB_CONCURRENCY_SA_RESTART to the "concurrency_mode" field of the passed KYFGLib_InitParameters instance.
The 1st approach is preferred over the 2nd one because using. KYFGLIB_CONCURRENCY_SA_RESTART may impact stream performance in certain circumstances. This is because what this flag usually means is that your blocking thread will still be interrupted by a signal, but the operating system will just save that thread state, switch context to signal handling procedure and then restore the context to proceed with the blocking call.