Is POSIX message queue implimentation correct?
joel.sherrill at OARcorp.com
Thu May 10 19:59:36 UTC 2001
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
More information about the users