Messages in this thread | | | Date | Sun, 21 Sep 2014 15:38:10 +0200 | From | Manfred Spraul <> | Subject | Re: [PATCH] V1 1/2] ipc: let message queues use SIGEV_THREAD_ID with mq_notify |
| |
Hi Steven,
You wrote: > Currently the only thread-safe way of using mq_notify with message > queues is to use the SIGEV_THREAD option. Could you explain what you mean with "only thread-safe way"? I'm a bit relunctant to extend mq_notify() without understanding the reason.
What about: - use sigprocmask() - create one worker thread - then in a loop in that worker thread: use sigwaitinfo() or signalfd() to collect the signals.
And one point I don't like: Within timer_create(): > SIGEV_THREAD_ID (Linux-specific) > [...] > The sigev_notify_thread_id field specifies a kernel thread ID, that > is, the value returned by clone(2) or gettid(2). Does that mean that SIGEV_THREAD_ID is guaranteed to remain Linux-specific, it's implicitely linked to the Linux clone()/gettid() threading model?
> This flag is intended only for use by threading libraries.
-- Manfred
| |