From: "Martijn Sipkema" <m.j.w.sipkema@student.tudelft.nl>
To: "Jakub Jelinek" <jakub@redhat.com>
Cc: <linux-kernel@vger.kernel.org>,
"Ulrich Drepper" <drepper@redhat.com>,
"Roland McGrath" <roland@redhat.com>
Subject: Re: POSIX message queues should not allocate memory on send
Date: Fri, 14 May 2004 13:42:02 +0100 [thread overview]
Message-ID: <001001c439b0$db1af1e0$161b14ac@boromir> (raw)
In-Reply-To: 20040514104012.GE30909@devserv.devel.redhat.com
> On Fri, May 14, 2004 at 12:09:46PM +0100, Martijn Sipkema wrote:
> > You are correct; defaults are indeed needed. The current default value
> > for mq_msgsize seems rather large considering that mq_msgsize*mq_maxmsg
> > bytes will have to be allocated on queue creation. If variable sized
large
> > payload messages are needed one might consider using shared memory in
> > combination with a message queue.
> >
> > My main point was that mq_send()/mq_timedsend() may not return ENOMEM
> > and I am positive I did not misread the standard on that.
>
> Even that is not clear.
>
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html#tag_02_03
> " Implementations may support additional errors not included in this
list,
> may generate errors included in this list under circumstances other
than
> those described here, or may contain extensions or limitations that
> prevent some errors from occurring. The ERRORS section on each
> reference page specifies whether an error shall be returned, or
whether
> it may be returned. Implementations shall not generate a different
error
> number from the ones described here for error conditions described in
> this volume of IEEE Std 1003.1-2001, but may generate additional
errors
> unless explicitly disallowed for a particular function."
>
> Explicitely disallowed in the general section is only EINTR for the THR
> option functions unless explitely listed for that function and nothing
else.
>
> I don't see ENOMEM explicitly forbidden for mq_send/mq_timedsend nor
> any wording in mq_open description which would require the buffers to
> be preallocated.
Indeed maybe returning ENOMEM from mq_send() is conforming to the
standard. Perhaps returning ENOMEM instead of ENOSPC from
mq_open() to indicate that there is unsufficient space for the creation of
a new queue isn't; I'm no longer sure.
What _is_ clear from the standard is that a queue is supposed to be
allocated on creation, even if it may not be required. Why else would
ENOSPC be explicitely listed for mq_open() when creating a new
queue, but not for mq_send()/mq_timedsend()?
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?
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.
--ms
next prev parent reply other threads:[~2004-05-14 11:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-14 10:30 POSIX message queues should not allocate memory on send Martijn Sipkema
2004-05-14 9:51 ` Jakub Jelinek
2004-05-14 11:09 ` Martijn Sipkema
2004-05-14 10:40 ` Jakub Jelinek
2004-05-14 12:42 ` Martijn Sipkema [this message]
2004-05-14 15:57 ` Ulrich Drepper
2004-08-15 0:12 ` Martijn Sipkema
2004-05-14 16:58 ` Chris Wright
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001001c439b0$db1af1e0$161b14ac@boromir' \
--to=m.j.w.sipkema@student.tudelft.nl \
--cc=drepper@redhat.com \
--cc=jakub@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.