<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2020 at 2:31 PM Martin Erik Werner <<a href="mailto:martinerikwerner@gmail.com">martinerikwerner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
In the documentation for rtems_message_queue_{send,urgent} there are<br>
two limit-related statuses:<br>
<br>
* - ``RTEMS_UNSATISFIED``         <br>
  - out of message buffers        <br>
* - ``RTEMS_TOO_MANY``            <br>
  - queue's limit has been reached<br>
<br>
What is the difference between these?</blockquote><div><br></div><div>It looks like a documentation error to me. RTEMS_UNSATISFIED is returned</div><div>on receive when you poll and there isn't a message pending. Looking at </div><div>coremsgsubmit.c, I don't see it being returned. </div><div><br></div><div>Can you raise a ticket, please?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Superficially I would guess that they both indicate that the queue<br>
already has the maximum amount of messages pending?<br>
<br>
>From a brief look at the code, my guess would be that RTEMS_UNSATISFIED<br>
cannot be returned by this function?<br></blockquote><div><br></div><div>Agreed. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
While digging in the code, I also noticed that if<br>
RTEMS_SCORE_COREMSG_ENABLE_BLOCKING_SEND is set, the<br>
_CORE_message_queue_Submit() function can return<br>
STATUS_MESSAGE_QUEUE_WAIT_IN_ISR which translates to<br>
RTEMS_INTERNAL_ERROR, is this status deliberately omitted from the<br>
documentation for rtems_message_queue_{send,urgent}?<br></blockquote><div><br></div><div>This is only enabled for POSIX message queues which enable blocking</div><div>send.See mq_send man page or Google "mq_send site:<a href="http://opengroup.org">opengroup.org</a>"</div><div>for the POSIX definition.</div><div><br></div><div>You can never block on a Classic API message queue send/urgent, so</div><div>the RTEMS_INTERNAL_ERROR seems reasonable. And I wonder</div><div> </div><div>Looking at the Linux man page, it returns EAGAIN if "The queue was </div><div>full, and the O_NONBLOCK flag was set for the message queue </div><div>description referred to by mqdes." </div><div><br></div><div>Since the table maps STATUS_MESSAGE_QUEUE_WAIT_IN_ISR<br>to ENOMEM, this also looks like a bug which is also (hopefully) documented</div><div>to return the same error in the POSIX mq_send RTEMS documentation.</div><div><br></div><div>So it looks like another bug to file. Please. </div><div><br></div><div>Good eye and analysis. Documentation bugs rarely get reported and I</div><div>really do appreciate it.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Martin Erik Werner <<a href="mailto:martinerikwerner@gmail.com" target="_blank">martinerikwerner@gmail.com</a>><br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>