From: Manfred Spraul <manfred@colorfullife.com>
To: "Peter Wächtler" <pwaechtler@mac.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, torvalds@osdl.org,
bo.z.li@intel.com
Subject: Re: [PATCH] [2/2] posix message queues
Date: Fri, 03 Oct 2003 20:16:22 +0200 [thread overview]
Message-ID: <3F7DBCF6.3050407@colorfullife.com> (raw)
In-Reply-To: <1065196646.3682.54.camel@picklock.adams.family>
Peter Wächtler wrote:
>+
>+#if 0
>+/* don't use fget() to avoid the fput() for speed reason
>+ * on create/open the refcount is 1 and decremented on close
>+ * if you have a multithreaded app where one thread closes
>+ * the mqueue while another thread operates on it -> possible crash
>+ * the spec says the behavior is undefined
>+ * separate processes are not affected
>+ */
>
Could you remove that block, instead of just disabling it? Bugs spread
at an incredible rate...
The right approach to avoid the cost of the fget is fget_light. But
that's an optimization, it can be added later.
>+
>+static void local_remove_wait_queue(wait_queue_head_t *q, wait_queue_t * wait)
>+{
>+ spin_lock(&q->lock);
>+ __remove_wait_queue(q, wait);
>+ spin_unlock(&q->lock);
>+}
>
What's the difference between remove_wait_queue() and
local_remove_wait_queue?
>+ queue->q_lspid = current->pid;
>+ queue->q_cbytes += msg_len;
>+ atomic_add(msg_len, &msg_bytes);
>
You are accounting posix messages in the sysv msg variables. Is that
something we want, or should posix messages have their own accounting
variables? I don't know what's better, but it should be discussed.
>+ queue->q_qnum++;
>+ inode->i_size = queue->q_qnum;
>+ inode->i_mtime = CURRENT_TIME;
>+
>+ if (waitqueue_active(&q->wait_recv)) {
>+ /* wake up all waiters to serve the highest prio waiter */
>+ wake_up_interruptible_all(&q->wait_recv);
>
Would it be possible to sort the waiters according to their prio?
wake_all is always bad.
>+ } else {
>+ /* since there was no synchronously waiting process for message
>+ * we notify it when the state of queue changed from
>+ * empty to not empty */
>+ if (q->notify_pid != 0 && queue->q_qnum == 1) {
>+ /* TODO: Add support for sigev_notify==SIGEV_THREAD
>+ * we should create a thread in userspace
>+ */
>
Is that comment still correct? You wrote that it's supported in user space.
It looks good.
--
Manfred
next prev parent reply other threads:[~2003-10-03 18:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-03 15:59 [PATCH] [2/2] posix message queues Peter Wächtler
2003-10-03 18:16 ` Manfred Spraul [this message]
2003-10-05 12:42 ` Peter Wächtler
2003-10-05 14:39 ` Arjan van de Ven
2003-10-05 15:58 ` Ulrich Drepper
2003-10-03 22:22 ` Jakub Jelinek
2003-10-05 12:42 ` Peter Wächtler
2003-10-04 6:39 ` Ulrich Drepper
-- strict thread matches above, loose matches on Subject: below --
2003-11-25 11:42 [PATCH] 2/2 POSIX " Michal Wronski
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=3F7DBCF6.3050407@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=akpm@osdl.org \
--cc=bo.z.li@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pwaechtler@mac.com \
--cc=torvalds@osdl.org \
/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.