Function safety
Function safety refers to whether or not it's safe to use the multimedia renderer API functions in certain situations.
All multimedia renderer API functions are thread-safe and behave as documented even in a multithreaded environment.
For those API functions that take explicit handles, no more than one thread may use the same handle at the same time, except for event-processing API calls.
- One thread sends control commands to the context
and
- Another thread fetches events and state updates using the mmr_event_*() functions:
API functions are neither interrupt-safe nor signal-safe. Consequently, you shouldn't call them in an interrupt handler or signal handler.
For more information on how QNX defines function safety situations outside of the POSIX context, refer to the
What's in a Function Description?
section in the C Library Reference.
Classification:
| Safety | |
|---|---|
| Cancellation point | Read the Caveats |
| Interrupt handler | No |
| Signal handler | No |
| Thread | Yes |
Caveats:
As long as you haven't enabled asynchronous cancellation, mmr_event_wait() is safe to cancel. If no event is already available and mmr_event_wait() needs to block, the call is a cancellation point. If the system returns an event without mmr_event_wait() blocking, it's unspecified whether the call is a cancellation point or not.
Any other multimedia renderer API library function may contain a cancellation point. However, cancelling a thread while it's executing an API function can cause leaks or leave data structures in a bad state. If you need to call API functions from a thread that might be cancelled during the call or might already have a pending cancellation request, then disable cancellation for the duration of the call.