Chandan U commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3986#note_142101 Hello @gedare, I’ve been looking into this issue for gsoc'26 contribution and went through the relevant message queue send paths across Classic, Posix and Score APIs. I wanted to share my current understanding and clarify a few doubts. **Findings from code study** 1\. POSIX APIs:- * mq_send() calls \_POSIX_Message_queue_Send_support(), which eventually invokes \_CORE_message_queue_Submit(). * Blocking behavior depends on O_NONBLOCK: * If not set wait = true * If set wait = false * mq_timedsend() also uses \_POSIX_Message_queue_Send_support(), but passes a timeout via \_Thread_queue_Context_set_timeout_argument() and an enqueue callout for watchdog handling. So in POSIX, both blocking and timeout paths of \_CORE_message_queue_Submit() are used. 2\. Classic API:- * rtems_message_queue_send() calls \_CORE_message_queue_Send() with wait = false always. * \_CORE_message_queue_Send() then routes into \_CORE_message_queue_Submit() internally, but only the non-blocking path is used since wait = false always. So Classic send never uses the wait == true path in the CORE layer. **Observations** >From the implementation of \_CORE_message_queue_Submit(), there is support for: * Blocking send * Sender wait queues * Timeout via thread queue/watchdog (when configured) However, this capability appears to be used only by POSIX APIs and not exposed through Classic APIs **Doubts / Questions** 1\. Was the non-blocking design of rtems_message_queue_send() an intentional Classic API design choice for determinism and simplicity, or is there scope of interest in extending Classic MQs to support blocking/timed send? 2\. Classic send goes through \_CORE_message_queue_Send() rather than calling \_CORE_message_queue_Submit() directly like POSIX. Is this layering mainly for API abstraction reasons? I’d appreciate any guidance on whether I’m interpreting the architecture correctly and how this relates to the original issue discussion. Thanks! -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3986#note_142101 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
