public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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




  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox