Is POSIX message queue implimentation correct?

Phil Torre ptorre at zetron.com
Thu May 10 18:24:42 UTC 2001


We're trying to use parts of the POSIX API without having the 1003.*
spec available, so I could be totally wrong about this...

We want a POSIX message queue which is blocking on read but non-
blocking on write (so the receiving task can sleep on the queue,
but senders won't block if the queue is full).  I thought the POSIX
way to do this was to have the receiver create the queue without
specifying O_NONBLOCK, but to have the senders open the queue with
O_NONBLOCK.  (On the theory that the blocking flag was an attribute
of the per-task queue descriptor, rather than the queue itself.)

RTEMS POSIX doesn't seem to do it this way.  In mqueueopen.c, mq_open()
checks to see if the named queue exists, and if so just returns the
same descriptor that the creator received.

(We can get the behavior we need by creating the queue non-blocking
and having the receiving task request message notification and then
going to sleep.  I'm just curious as to why it works as it does:
Is this really how POSIX does it, or is the RTEMS implimentation of
mq_open limited by the fact that we're all one big process?)

-- 

=====================================================================
Phil Torre                               phone: 425-820-6363 x234
Design Engineer                          email: ptorre at zetron.com
Switching Systems Group                    fax: 425-820-7031
Zetron, Inc.                               web: http://www.zetron.com




More information about the users mailing list