Chandan U commented on a discussion on cpukit/include/rtems/score/coremsg.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1164#note_148528 > Chain_Control Inactive_messages; > }; > > +#if defined( RTEMS_POSIX_API ) && ( MQ_PRIO_MAX <= 255 ) > +typedef struct { > + CORE_message_queue_Control Base; > + Priority_bit_map_Control Queue; Hi @joel , thank you for the review. I completely understand the concern regarding the per instance memory overhead. I had proceeded with the bitmap approach based on the earlier [discourse Thread ](https://users.rtems.org/t/gsoc-26-lower-message-priority-range-optimization/496/3?u=chandanuvm)discussion with @gedare and @sebhub's recent approval of the memory tradeoff for the 32 priority limit. But I agree that the array of Chain_Control instances makes the base MQ object too large per message queue instance. I will pivot the design to use the Red-Black tree implementation as you and Sebastian initially suggested, I will use the existing red black tree in the kernel , and update the draft MR shortly. @joel @sebhub @gedare Can you please guide me through this since I've included bitmap + priority bucket implementation solution in the proposal, how should I go about it. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1164#note_148528 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
