Xinhong Hu commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_143086 Hi @joel , @gedare Thank you for the thoughtful discussion. I've been prototyping the per-instance approach Joel suggested: adding an RTEMS-specific field `mq_ispriority` to struct `mq_attr`. This allows each queue to independently choose FIFO or priority wake-up order, with a default of FIFO to maintain backward compatibility. My tests on RTEMS 7 confirm that setting `mq_ispriority = 1` correctly wakes a higher-priority thread that blocks later. Regarding Gedare's point about application configuration: I think per-instance control already gives applications the ability to configure individual queues. However, to also support system-wide defaults, we could add a configuration macro in `<rtems/confdefs.h>` (e.g., `CONFIGURE_POSIX_MESSAGE_QUEUE_DEFAULT_DISCIPLINE`) that sets the initial value of `mq_ispriority` for queues created with a NULL attribute. This would allow integrators to change the global default without modifying each `mq_open` call, while still permitting per-queue overrides. For my GSoC project, I propose to implement both the per-instance field and the global configuration option. The core deliverables would be: 1. Extend struct `mq_attr` with `mq_ispriority` (guarded by `#ifdef __RTEMS__`). 2. Modify `mq_open()` to interpret this field and pass the discipline to the core message queue. 3. Add a configuration macro in `<rtems/confdefs.h>` to set the default discipline. 4. Provide comprehensive tests and documentation. I believe this scope is manageable within the GSoC timeframe and fully resolves #3791 while offering flexibility for future needs. I'd appreciate your feedback on whether this plan aligns with your expectations. If you prefer a simpler approach (only per-instance or only global), I can adjust accordingly. Thank you for your guidance! -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_143086 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
