Having trouble tracking down answer to usage of SIGEV_THREAD...
When one sets SIGEV_THREAD as the notify method in sigevent struct, is it correct to assume that async-signal-safe functions must still be used within the notify_function to be invoked as the handler?
Also - is it correct to assume the thread is run as "detached"?
For example
notify thread
void my_thread(union sigval my_data)
{
// is this ok or not (two non async-signal-safe functions)?
printf("in the notify function\n");
mq_send();
}
main function
(...)
se.sigev_notify = SIGEV_THREAD;
se.sigev_value.sival_ptr = &my_data;
se.sigev_notify_function = my_thread;
se.sigev_notify_attributes = NULL;
(...)
Please provide a reference if possible.
No, you don't need to use only async-signal-safe functions, because POSIX does not place any such limitation on the SIGEV_THREAD
function. (The whole point of SIGEV_THREAD
is that it lets you handle asychronous notifications in a less constrained environment than a signal handler).
As far as the thread being detached, POSIX says:
The function shall be executed in an environment as if it were the start_routine for a newly created thread with thread attributes specified by
sigev_notify_attributes
. Ifsigev_notify_attributes
isNULL
, the behavior shall be as if the thread were created with the detachstate attribute set toPTHREAD_CREATE_DETACHED
. Supplying an attributes structure with a detachstate attribute ofPTHREAD_CREATE_JOINABLE
results in undefined behavior. The signal mask of this thread is implementation-defined.
This means: you must either leave sigev_notify_attributes
as NULL
, or set it to an attributes structure with the detachstate set to PTHREAD_CREATE_DETACHED
- in both cases the thread will be created detached.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With