Is POSIX message queue implimentation correct?

[Joel Sherrill]

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

The UNIX98 version of this at www.opengroup.org.  
 
> 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?)

Without some serious re-reading, I don't want to comment.  Your
interpretation is certainly reasonable and the one-process nature
of RTEMS could make it a valid but not as useful as possible
implementation.  If each open gets some secondary structure, then
it would be possible to do this.  Offhand, I don't know how much work 
would be required to change this.

Read unix98 and email back with your interpretation. 

> --
> 
> =====================================================================
> 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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985