GSOC 2026 : Messages Queue Improvement and fixes +Proof of work

Hi everyone,

I’m Priya Pandey (IIT Madras ECE) and I’m targeting the Message Queue Improvement and Fixes (#88) GSoC project. I’ve been studying the 4 blocking issues and want to start with #3791 (POSIX Message Queue thread release order)
from the gitlab discussion I came to know the actuall cause behind it and would try to implement the solution in upcoming days
I Have successfully completed GSOC -proof of work
here are the screen shots (it took 5 hrs for the toolchain to build)

thankyou …Will be updating with my work

Thanks, it looks like your git config user.name may not be your full name, please double check so that author attribution is correct.

You can add yourself to tracking/2026 · main · RTEMS / Programs / Google Summer of Code · GitLab.

There are already some topic threads related to this project. You can search for them here and join the conversation, or open new topics for specific questions related to the project that aren’t being addressed elsewhere.

Thankyou… we’ll update the username

Hello @gedare
I was looking into the blocking issues
and decided to go deeper into #3791
what I understood
it deals with POSIX message queues not waking up waiting threads by priority order—they stick to FIFO instead even when priority mode is set.

​I went deep with debugging on RTEMS 7, using GDB and test code to show low-priority threads getting unblocked first, despite priority functions being called. Also RTEMS needs flexibility without forcing changes, like switching to priority discipline in mq_open.c during creation as it may break breaks old apps

So there’s this idea in gitlab discussion : Add an RTEMS-only field called mq_ispriority_np to the mq_attr struct, defaulting to FIFO for safety. Apps can set it to 1 per queue for priority wakeup, Also we can have weak default attributes so apps override globally if needed, maybe via confdefs.h

I am trying to implement it and look into other issues as well…decided not to stay just for gsoc but for a longer run to work closely with systems and understand more precisely and refine my skills

Just want to confirm a thing … even if not as a part of gsoc will I be able to work on these issues relates to message queue?

thankyou for considering

Anyone is welcome to contribute at any time to RTEMS.