[RTEMS Project] #3857: Use EAGAIN for POSIX mq wait in ISR error

[RTEMS trac]

#3857: Use EAGAIN for POSIX mq wait in ISR error
---------------------------+----------------------------
 Reporter:  Joel Sherrill  |       Owner:  Joel Sherrill
     Type:  defect         |      Status:  closed
 Priority:  normal         |   Milestone:  5.1
Component:  posix          |     Version:  5
 Severity:  normal         |  Resolution:  fixed
 Keywords:                 |  Blocked By:
 Blocking:                 |
---------------------------+----------------------------
Changes (by Martin Erik Werner <martinerikwerner@…>):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"e22554535796fc29a7ed7c5e2338128e324a621d/rtems"
 e225545/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="e22554535796fc29a7ed7c5e2338128e324a621d"
 Use EAGAIN for POSIX mq wait in ISR error

 Modify the status code returned by _CORE_message_queue_Submit() when it
 detects a wait about to happen in an ISR (which would be deadly) to
 return a status which translated to EAGAIN instead of ENOMEM.

 This is only relevant for POSIX message queues, since Classic API message
 queues cannot block on send.

 The motivation is to match the "most related" errno value returned from
 mq_send() and mq_timedsend() according to POSIX, via Open Group:

   [EAGAIN]
       The O_NONBLOCK flag is set in the message queue description
       associated with mqdes, and the specified message queue is full.

 or via the RTEMS POSIX users documentation

   EAGAIN
     The message queue is non-blocking, and there is no room on the queue
     for another message as specified by the mq_maxmsg.

 Neither of these matches the case ofi avoided ISR wait perfectly, but
 they seem to be the closest equivalent, unless it is desirable to keep a
 new non-standard error for this case. It is presumed that this is not
 desirable.

 The previously returned ENOMEM error value is not documented in either
 the Open Group or the RTEMS POSIX uses documentation. A companion patch
 corrects the documentation to include this error condition.

 Based on the discussion in:
 https://lists.rtems.org/pipermail/devel/2020-January/056891.html

 closes #3857.

 Message-Id: <CAF9ehCW5P12ZkZja4UPYTbdBFUyC1VKVL-
 tU7nyUtvK1Lz2Z3g at mail.gmail.com>
 }}}

--
Ticket URL: <http://devel.rtems.org/ticket/3857#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project