Implement Message Queues for Structured IPC

Structured Message IPC

Message queues carry typed records with priorities instead of byte streams. SysV msgsnd/msgrcv and POSIX mq_open variants exist; both kernel modules maintain waiting receivers per queue.

Message Layout

Typical record:

• mtype: routing or priority key
• mbody: fixed or max-sized payload

For example, worker pool messages with mtype=1 for jobs and mtype=2 for control shutdown broadcast to all readers.

Why This Matters in Production

System V message queues predate and directly inspired the message-type-and-priority model that production brokers like RabbitMQ and ZeroMQ still expose today, letting unrelated processes exchange structured, typed messages without the strict FIFO-only constraint of a pipe. The kernel persistence this task highlights is a double-edged sword in practice: forgotten message queues from crashed test programs are a classic source of /proc/sys/kernel/msgmni exhaustion on long-running Linux servers, which is exactly why ipcs/ipcrm exist.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will implement send and receive with blocking on empty queues. The task asks you to handle partial queue limits and return EAGAIN on non-blocking full queue.