All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Jason Baron <jbaron@akamai.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: mtk.manpages@gmail.com, mingo@kernel.org, peterz@infradead.org,
	viro@ftp.linux.org.uk, normalperson@yhbt.net, m@silodev.com,
	corbet@lwn.net, luto@amacapital.net,
	torvalds@linux-foundation.org, hagen@jauu.net,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-api@vger.kernel.org
Subject: Re: [PATCH] epoll: add exclusive wakeups flag
Date: Tue, 15 Mar 2016 09:01:24 +1300	[thread overview]
Message-ID: <56E71894.4090607@gmail.com> (raw)
In-Reply-To: <56E711C3.8020008@akamai.com>

Hi Jason,

On 03/15/2016 08:32 AM, Jason Baron wrote:
> 
> 
> On 03/14/2016 01:47 PM, Michael Kerrisk (man-pages) wrote:
>> [Restoring CC, which I see I accidentally dropped, one iteration back.]

[...]

>>>>               values in events yield an error.  EPOLLEXCLUSIVE may  be
>>>>               used  only  in  an  EPOLL_CTL_ADD operation; attempts to
>>>>               employ  it  with  EPOLL_CTL_MOD  yield  an  error.    If
>>>>               EPOLLEXCLUSIVE has set using epoll_ctl(2), then a subse‐
>>>>               quent EPOLL_CTL_MOD on the same epfd, fd pair yields  an
>> b>>               error.  An epoll_ctl(2) that specifies EPOLLEXCLUSIVE in
>>>>               events and specifies the target file descriptor fd as an
>>>>               epoll  instance will likewise fail.  The error in all of
>>>>               these cases is EINVAL.
>>>>
>>>>    ERRORS
>>>>        EINVAL An invalid event type was specified along with  EPOLLEX‐
>>>>               CLUSIVE in events.
>>>>
>>>>        EINVAL op was EPOLL_CTL_MOD and events included EPOLLEXCLUSIVE.
>>>>
>>>>        EINVAL op  was  EPOLL_CTL_MOD  and  the EPOLLEXCLUSIVE flag has
>>>>               previously been applied to this epfd, fd pair.
>>>>
>>>>        EINVAL EPOLLEXCLUSIVE was specified in event and fd  is  refers
>>>>               to an epoll instance.
>>
>> Returning to the second sentence in this description:
>>
>>               When a wakeup event occurs and multiple epoll file descrip‐
>>               tors are attached to the same target file using EPOLLEXCLU‐
>>               SIVE, one or  more  of  the  epoll  file  descriptors  will
>>               receive  an  event with epoll_wait(2).
>>
>> There is a point that is unclear to me: what does "target file" refer to?
>> Is it an open file description (aka open file table entry) or an inode?
>> I suspect the former, but it was not clear in your original text.
>>
> 
> So from epoll's perspective, the wakeups are associated with a 'wait
> queue'. So if the open() and subsequent EPOLL_CTL_ADD (which is done via
> file->poll()) results in adding to the same 'wait queue' then we will
> get 'exclusive' wakeup behavior.
> 
> So in general, I think the answer here is that its associated with the
> inode (I coudn't say with 100% certainty without really looking at all
> file->poll() implementations). Certainly, with the 'FIFO' example below,
> the two scenarios will have the same behavior with respect to
> EPOLLEXCLUSIVE.

So, in both scenarios, *one or more* processes will get a wakeup?
(I'll try to add something to the text to clarify the detail we're 
discussing.)

> Also, the 'non-exclusive' mode would be subject to the same question of
> which wait queue is the epfd is associated with...

I'm not sure of the point you are trying to make here?

Cheers,

Michael


>> To make this point even clearer, here are two scenarios I'm thinking of.
>> In each case, we're talking of monitoring the read end of a FIFO.
>>
>> ===
>>
>> Scenario 1:
>>
>> We have three processes each of which
>> 1. Creates an epoll instance
>> 2. Opens the read end of the FIFO
>> 3. Adds the read end of the FIFO to the epoll instance, specifying
>>    EPOLLEXCLUSIVE
>>
>> When input becomes available on the FIFO, how many processes
>> get a wakeup?
>>
>> ===
>>
>> Scenario 3
>>
>> A parent process opens the read end of a FIFO and then calls
>> fork() three times to create three children. Each child then:
>>
>> 1. Creates an epoll instance
>> 2. Adds the read end of the FIFO to the epoll instance, specifying
>> EPOLLEXCLUSIVE
>>
>> When input becomes available on the FIFO, how many processes
>> get a wakeup?
>>
>> ===
>>
>> Cheers,
>>
>> Michael
>>
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

WARNING: multiple messages have this Message-ID (diff)
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Jason Baron <jbaron@akamai.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: mtk.manpages@gmail.com, mingo@kernel.org, peterz@infradead.org,
	viro@ftp.linux.org.uk, normalperson@yhbt.net, m@silodev.com,
	corbet@lwn.net, luto@amacapital.net,
	torvalds@linux-foundation.org, hagen@jauu.net,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-api@vger.kernel.org
Subject: Re: [PATCH] epoll: add exclusive wakeups flag
Date: Tue, 15 Mar 2016 09:01:24 +1300	[thread overview]
Message-ID: <56E71894.4090607@gmail.com> (raw)
In-Reply-To: <56E711C3.8020008@akamai.com>

Hi Jason,

On 03/15/2016 08:32 AM, Jason Baron wrote:
> 
> 
> On 03/14/2016 01:47 PM, Michael Kerrisk (man-pages) wrote:
>> [Restoring CC, which I see I accidentally dropped, one iteration back.]

[...]

>>>>               values in events yield an error.  EPOLLEXCLUSIVE may  be
>>>>               used  only  in  an  EPOLL_CTL_ADD operation; attempts to
>>>>               employ  it  with  EPOLL_CTL_MOD  yield  an  error.    If
>>>>               EPOLLEXCLUSIVE has set using epoll_ctl(2), then a subse‐
>>>>               quent EPOLL_CTL_MOD on the same epfd, fd pair yields  an
>> b>>               error.  An epoll_ctl(2) that specifies EPOLLEXCLUSIVE in
>>>>               events and specifies the target file descriptor fd as an
>>>>               epoll  instance will likewise fail.  The error in all of
>>>>               these cases is EINVAL.
>>>>
>>>>    ERRORS
>>>>        EINVAL An invalid event type was specified along with  EPOLLEX‐
>>>>               CLUSIVE in events.
>>>>
>>>>        EINVAL op was EPOLL_CTL_MOD and events included EPOLLEXCLUSIVE.
>>>>
>>>>        EINVAL op  was  EPOLL_CTL_MOD  and  the EPOLLEXCLUSIVE flag has
>>>>               previously been applied to this epfd, fd pair.
>>>>
>>>>        EINVAL EPOLLEXCLUSIVE was specified in event and fd  is  refers
>>>>               to an epoll instance.
>>
>> Returning to the second sentence in this description:
>>
>>               When a wakeup event occurs and multiple epoll file descrip‐
>>               tors are attached to the same target file using EPOLLEXCLU‐
>>               SIVE, one or  more  of  the  epoll  file  descriptors  will
>>               receive  an  event with epoll_wait(2).
>>
>> There is a point that is unclear to me: what does "target file" refer to?
>> Is it an open file description (aka open file table entry) or an inode?
>> I suspect the former, but it was not clear in your original text.
>>
> 
> So from epoll's perspective, the wakeups are associated with a 'wait
> queue'. So if the open() and subsequent EPOLL_CTL_ADD (which is done via
> file->poll()) results in adding to the same 'wait queue' then we will
> get 'exclusive' wakeup behavior.
> 
> So in general, I think the answer here is that its associated with the
> inode (I coudn't say with 100% certainty without really looking at all
> file->poll() implementations). Certainly, with the 'FIFO' example below,
> the two scenarios will have the same behavior with respect to
> EPOLLEXCLUSIVE.

So, in both scenarios, *one or more* processes will get a wakeup?
(I'll try to add something to the text to clarify the detail we're 
discussing.)

> Also, the 'non-exclusive' mode would be subject to the same question of
> which wait queue is the epfd is associated with...

I'm not sure of the point you are trying to make here?

Cheers,

Michael


>> To make this point even clearer, here are two scenarios I'm thinking of.
>> In each case, we're talking of monitoring the read end of a FIFO.
>>
>> ===
>>
>> Scenario 1:
>>
>> We have three processes each of which
>> 1. Creates an epoll instance
>> 2. Opens the read end of the FIFO
>> 3. Adds the read end of the FIFO to the epoll instance, specifying
>>    EPOLLEXCLUSIVE
>>
>> When input becomes available on the FIFO, how many processes
>> get a wakeup?
>>
>> ===
>>
>> Scenario 3
>>
>> A parent process opens the read end of a FIFO and then calls
>> fork() three times to create three children. Each child then:
>>
>> 1. Creates an epoll instance
>> 2. Adds the read end of the FIFO to the epoll instance, specifying
>> EPOLLEXCLUSIVE
>>
>> When input becomes available on the FIFO, how many processes
>> get a wakeup?
>>
>> ===
>>
>> Cheers,
>>
>> Michael
>>
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-03-14 20:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08  3:23 [PATCH] epoll: add exclusive wakeups flag Jason Baron
2015-12-08  3:23 ` [PATCH] epoll: add EPOLLEXCLUSIVE flag Jason Baron
2015-12-08  3:23   ` Jason Baron
2016-01-28  7:16 ` [PATCH] epoll: add exclusive wakeups flag Michael Kerrisk (man-pages)
2016-01-28  7:16   ` Michael Kerrisk (man-pages)
2016-01-28 17:57   ` Jason Baron
2016-01-29  8:14     ` Michael Kerrisk (man-pages)
2016-02-01 19:42       ` Jason Baron
2016-02-01 19:42         ` Jason Baron
2016-03-10 18:53       ` Jason Baron
2016-03-10 19:47         ` Michael Kerrisk (man-pages)
2016-03-10 19:47           ` Michael Kerrisk (man-pages)
2016-03-10 19:58         ` Michael Kerrisk (man-pages)
2016-03-10 19:58           ` Michael Kerrisk (man-pages)
2016-03-10 20:40           ` Jason Baron
2016-03-10 20:40             ` Jason Baron
2016-03-11 20:30             ` Michael Kerrisk (man-pages)
2016-03-11 20:30               ` Michael Kerrisk (man-pages)
     [not found]               ` <56E32FC5.4030902@akamai.com>
     [not found]                 ` <56E353CF.6050503@gmail.com>
     [not found]                   ` <56E6D0ED.20609@akamai.com>
2016-03-14 17:47                     ` Michael Kerrisk (man-pages)
2016-03-14 19:32                       ` Jason Baron
2016-03-14 19:32                         ` Jason Baron
2016-03-14 20:01                         ` Michael Kerrisk (man-pages) [this message]
2016-03-14 20:01                           ` Michael Kerrisk (man-pages)
2016-03-14 21:03                           ` Michael Kerrisk (man-pages)
2016-03-14 21:03                             ` Michael Kerrisk (man-pages)
2016-03-14 22:35                             ` Jason Baron
2016-03-14 23:09                               ` Madars Vitolins
2016-03-14 23:26                               ` Michael Kerrisk (man-pages)
2016-03-14 23:26                                 ` Michael Kerrisk (man-pages)
2016-03-15  2:36                                 ` Jason Baron
2016-03-15  2:36                                   ` Jason Baron

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=56E71894.4090607@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=hagen@jauu.net \
    --cc=jbaron@akamai.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=m@silodev.com \
    --cc=mingo@kernel.org \
    --cc=normalperson@yhbt.net \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ftp.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 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.