Joel Sherrill commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_142896 I am glad you ran that down to the one place during initialization. The POSIX standard does not say much about thread priority and message queues. [mq_receive](https://pubs.opengroup.org/onlinepubs/009696699/functions/mq_receive.html) has a little information referencing the "Priority Scheduling option." Searching the PDF of POSIX Issue 8, that phrase only occurs in _mq_send()_ and _mq_receive()_ I think there is some terminology mixup. There is a section Priority Scheduling (2.8.4) in the background and __POSIX_PRIORITY_SCHEDULING_ is documented as an option. Ignoring all that, I think your change is the right way to do what POSIX asks. But it locks RTEMS into having all POSIX MQs have priority blocking which is a behavior change from previous RTEMS versions. Having control over blocking discipline on a per instance basis would be better. [mq_setattr()](https://pubs.opengroup.org/onlinepubs/009696699/functions/mq_setattr.html) doesn't let you change message size or maximum on the fly -- it has to be set at _mq_create()_ and this would be a similar attribute. After all this writing, the simple change would be to add a field to _mq_attr_ for FIFO or priority blocking. Something like _mq_ispriority_ and the default would be FIFO and that would be a 0 value. ``` static const struct mq_attr _POSIX_Message_queue_Default_attributes = { .mq_maxmsg = 10, .mq_msgsize = 16 }; `` That structure **should** initialize every field. :( ` A grander idea which builds on adding discipline choice is having an application configuration option as found in _<rtems/confdefs.h>_ which generates the default POSIX MQ attributes. This would replace this from from _mqopen.c_. This structure already has more fields than shown and could have another to specify if an MQ instance being created with _mq_open()_ is FIFO or priority blocking. The current default attributes structure is defined in _mqueue.h_ in the RTEMS source. This sounds like a lot but just adding something like _mq_ispriority_ to _mq_attr_ is enough to give a lot more flexibility and make priority blocking an option to applications which want it on a per MQ instance basis. I likely have written more English than code is required. And the grander idea may not be worth the trouble. @gedare thoughts? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_142896 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
