"too many" vs "unsatisfied" status from msg send

[Joel Sherrill]

On Thu, Jan 16, 2020 at 2:31 PM Martin Erik Werner <
martinerikwerner at gmail.com> wrote:

> Hi,
>
> In the documentation for rtems_message_queue_{send,urgent} there are
> two limit-related statuses:
>
> * - ``RTEMS_UNSATISFIED``
>   - out of message buffers
> * - ``RTEMS_TOO_MANY``
>   - queue's limit has been reached
>
> What is the difference between these?


It looks like a documentation error to me. RTEMS_UNSATISFIED is returned
on receive when you poll and there isn't a message pending. Looking at
coremsgsubmit.c, I don't see it being returned.

Can you raise a ticket, please?

Superficially I would guess that they both indicate that the queue
> already has the maximum amount of messages pending?
>
> From a brief look at the code, my guess would be that RTEMS_UNSATISFIED
> cannot be returned by this function?
>

Agreed. :)


>
> While digging in the code, I also noticed that if
> RTEMS_SCORE_COREMSG_ENABLE_BLOCKING_SEND is set, the
> _CORE_message_queue_Submit() function can return
> STATUS_MESSAGE_QUEUE_WAIT_IN_ISR which translates to
> RTEMS_INTERNAL_ERROR, is this status deliberately omitted from the
> documentation for rtems_message_queue_{send,urgent}?
>

This is only enabled for POSIX message queues which enable blocking
send.See mq_send man page or Google "mq_send site:opengroup.org"
for the POSIX definition.

You can never block on a Classic API message queue send/urgent, so
the RTEMS_INTERNAL_ERROR seems reasonable. And I wonder

Looking at the Linux man page, it returns EAGAIN if "The queue was
full, and the O_NONBLOCK flag was set for the message queue
description referred to by mqdes."

Since the table maps STATUS_MESSAGE_QUEUE_WAIT_IN_ISR
to ENOMEM, this also looks like a bug which is also (hopefully) documented
to return the same error in the POSIX mq_send RTEMS documentation.

So it looks like another bug to file. Please.

Good eye and analysis. Documentation bugs rarely get reported and I
really do appreciate it.

--joel

> --
> Martin Erik Werner <martinerikwerner at gmail.com>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200116/40d925de/attachment.html>