Got a chance to investigate the test case. For each notification
request registered, only one notification will be sent. Once
a notification is sent to the process, the registration is removed.
The process has to re-register the notification again to receive the
next notification. This is document
Ignore my previous reply. The explanation is not correct. I
need to investigate the test case and get back.
-Prakash.
prakash sangappa wrote:
Hi Micheal,
Yes, there is a problem here. Looking at the code and your test output,
we can see that there is a race condition between __mq_timedsend
Hi Micheal,
Yes, there is a problem here. Looking at the code and your test output,
we can see that there is a race condition between __mq_timedsend()
and __mq_timedreceive(). Note that __mq_timedrecieve() does not hold the
mq_exclusive mutex when calling the sem_trywait(&mqhp->mq_notempty)
Hey Bart and Prakash,
first of all: A happy New Year!
I have seen that a good old RFE 4017841 to implement SIGEV_THREAD
notification type of timers, message queues and asynchronous I/O
has successfully been committed a couple of months ago
in our next version of Solaris. :-) (ca. build 40 or so)
