Joel Sherrill commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_143088 Your survey looks good. I would say Linux is not compliant since it is using LIFO. And unfortunately, POSIX gives us the "if you support the __POSIX_PRIORITY_SCHEDULING_ **option**" then the blocking discipline for all message queues changes. This is a system implementation decision so there really is not portability. You cannot control what behavior your application is going to get. I think as a minimum, RTEMS should support a configuration option to toggle between FIFO and priority. If we don't do that much, then existing applications will have a change in behavior that will break backwards compatibility. Adding a field to _mq_attr_ gives the user fine gained control on each message queue instance. I think adding an _mq_is_priority_ to out _mq_attr_ structure is a good move. And giving the user a way to define their own default _mq_attr_ instance allows them change each entry in the default structure. It would let them also override maximum message size and maximum pending messages. It would take adding to confdefs.h a macro default for each field in the structure and another to turn on using them. The current default attributes could be a weak symbol that is overridden. I think this solution may also be needed for POSIX semaphores. They have the same language for the __POSIX_PRIORITY_SCHEDULING_ option -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3791#note_143088 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
