From: "Paton J. Lewis" <palewis@adobe.com>
To: Christof Meerwald <cmeerw@cmeerw.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Jason Baron <jbaron@redhat.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Paul Holland <pholland@adobe.com>,
Davide Libenzi <davidel@xmailserver.org>
Subject: Re: [PATCH] epoll: Improved support for multi-threaded clients
Date: Mon, 18 Jun 2012 16:24:35 -0700 [thread overview]
Message-ID: <6.2.5.6.2.20120618161807.031eb6c8@adobe.com> (raw)
In-Reply-To: <20120616184707.GA22656@edge.cmeerw.net>
Christof,
We believe that EPOLLONESHOT is required in order to make any
sensible use of calling epoll_wait on a single epoll set concurrently
in multiple threads. So in that sense the new functionality is really
only useful for coordinating resource deletion between threads when
using EPOLLONESHOT. However, when EPOLLONESHOT is not used,
EPOLL_CTL_DISABLE still disables the item, and can be used solely for
that purpose if the caller intends to re-enable the item via
EPOLL_CTL_MOD and doesn't wish to incur the additional overhead
associated with deleting and re-adding an item.
Thank you,
Pat
At 6/16/2012 11:47 AM, Christof Meerwald wrote:
>On Mon, 11 Jun 2012 15:34:49 -0700, Paton Lewis wrote:
> > This patch introduces the new epoll_ctl command EPOLL_CTL_DISABLE, which
> > disables the associated epoll item and returns -EBUSY if the
> epoll item is not
> > currently in the epoll ready queue. This allows multiple threads to use a
> > mutex to determine when it is safe to delete an epoll item and
> its associated
> > resources. This allows epoll items to be deleted and closed efficiently and
> > without error.
>
>Do you assume that EPOLLONESHOT is being used for this to work or
>would you expect your patch to also address the case where
>EPOLLONESHOT is not used?
>
>
>Christof
>
>--
>
>http://cmeerw.org sip:cmeerw at cmeerw.org
>mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
next prev parent reply other threads:[~2012-06-18 23:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 22:34 [PATCH] epoll: Improved support for multi-threaded clients Paton Lewis
2012-06-13 23:27 ` Andrew Morton
2012-06-18 21:58 ` Paton J. Lewis
2012-06-19 23:42 ` Andrew Morton
2012-06-16 18:47 ` Christof Meerwald
2012-06-18 23:24 ` Paton J. Lewis [this message]
2012-06-19 18:17 ` Christof Meerwald
2012-06-29 21:43 ` Paton J. Lewis
2012-07-09 18:45 ` Christof Meerwald
2012-08-03 1:37 ` Paton J. Lewis
2012-08-14 20:21 ` Christof Meerwald
2012-08-14 22:13 ` Paton J. Lewis
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=6.2.5.6.2.20120618161807.031eb6c8@adobe.com \
--to=palewis@adobe.com \
--cc=cmeerw@cmeerw.org \
--cc=davidel@xmailserver.org \
--cc=jbaron@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pholland@adobe.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).