Exercise 2: A Capacity-1 Message Queue Still Preserves Whole Messages — Possible Solution
====================================================================

THE TEST
------------------------------
    mq = MessageQueue(..., capacity=1)   # the tightest possible queue
    messages = [b"one", b"two-longer", b"3"]   # genuinely different lengths
    programs[sender.pid] = [('send', m) for m in messages]
    programs[receiver.pid] = [('receive',) for _ in messages]

RESULT
------------------------------
    sent (varying lengths): [b'one', b'two-longer', b'3']
    received, in order: [b'one', b'two-longer', b'3']

Every message arrives complete and in the exact order sent, even
though 'two-longer' is more than 3x the length of '3'.

WHY CAPACITY DOESN'T AFFECT MESSAGE-BOUNDARY CORRECTNESS
------------------------------
MessageQueue's own internal storage is a real Python deque of whole
message objects (self.messages), not a fixed-size byte array indexed
by position. capacity only controls how many DECK ENTRIES (not bytes)
the empty/full semaphores allow to exist at once before a sender must
wait for a receiver to catch up. With capacity=1, the sender can only
ever get exactly one message ahead of the receiver -- but that one
message, whatever its length, is still stored and retrieved as a
single, complete, atomic object. There's no code path anywhere in
try_send()/try_receive() that ever looks at a message's own byte
length to decide how much "room" it takes up -- length is completely
irrelevant to the semaphore counting, which only ever counts whole
messages.

WHY THIS IS THE KEY DIFFERENCE FROM A PIPE
------------------------------
A real pipe's own capacity IS measured in bytes, so a longer message
genuinely consumes more of the buffer's own limited space, and a
message that's too large for the whole buffer can't even be written
in one uninterrupted burst -- exactly the scenario that made Exercise
1's own length-prefixing fail under contention. A MessageQueue sidesteps
this entirely: capacity is "how many messages," not "how many bytes,"
so a message's own internal length is never something the queue's own
synchronization logic has to reason about at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
Deliberately choosing messages of very different lengths (3 bytes,
10 bytes, 1 byte) at the smallest possible capacity confirms the
queue's own correctness genuinely doesn't depend on messages being
similar in size or the queue having "enough room" -- the guarantee
holds structurally, the same way Chapter 3's own capacity-1 bounded
buffer exercise proved byte-level correctness didn't depend on buffer
size either.