Re: POSIX message queues should not allocate memory on send

[Ulrich Drepper <drepper@redhat.com>]

Martijn Sipkema wrote:

> Indeed maybe returning ENOMEM from mq_send() is conforming to the
> standard.

Indeed, it is.


> What _is_ clear from the standard is that a queue is supposed to be
> allocated on creation, even if it may not be required.

Nothing is clear when it comes to the behavior.  There are certainly
some aspects of a possible implementation which the designers of the
APIs had in mind, but this is absolutely no requirement.


> What use is a message queue for a realtime application when on
> mq_send() it may have to wait for memory allocation that may even
> fail?

That's a completely different issue.  You want everybody to suffer
because of the requirements of have.  This is the same as if you would
demand the overcommit is disable.

Yes, there are situations where the allocation-on-demand is not
desirable and the POSIX API description is indeed hinting at such uses.
 But the APIs are useful even without having such hard requirements and
so far the people who developed the code have not seen this hard
realtime requirement.

If you have such requirements I suggest that you sit done and write some
extensions.  I.e., do not replace the current default behavior, but
instead make it possible to force pre-allocation.  I'd say the natural
way is to define a O_* flag which only mq_open() and mq_setattr()
understands.  The former will get it in the second parameter, the latter
via the mq_flags field in the incoming struct mq_attr structure.
Something like O_PREALLOCATE.  Again, the flag would only be needed for
message queues, so a bit other than the ones used by mq_open() can be
reused.


> Even if POSIX allows errors to be returned that are not in the function's
> ERRORS list, I don't think one should do this if it can be avoided.

Do your part to fulfill your niche-requirements.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖