epoll(7) redux

epoll(7) redux

[Sam Varshavchik]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

Q2

    Can two epoll sets wait for the same file descriptor? If so, are events 
reported to both epoll file descriptors?

A2

    Yes, and events would be reported to both. However, it is not 
recommended.

=========

It's not clear what "not recommended" means. Furthermore, I don't think 
there's anything wrong with two epoll file descriptors waiting for different 
events on the same file descriptor. One's waiting for POLLIN, the other for 
POLLOUT. What's wrong with that?


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: epoll(7) redux

[Michael Kerrisk]

On Wed, Apr 9, 2008 at 1:07 PM, Sam Varshavchik <mrsam-W1w4QoW4mIDgLSHwZvcCBg@public.gmane.org> wrote:
> Q2
>
>   Can two epoll sets wait for the same file descriptor? If so, are events
> reported to both epoll file descriptors?
>
> A2
>
>   Yes, and events would be reported to both. However, it is not recommended.
>
> =========
>
> It's not clear what "not recommended" means. Furthermore, I don't think
> there's anything wrong with two epoll file descriptors waiting for different
> events on the same file descriptor. One's waiting for POLLIN, the other for
> POLLOUT. What's wrong with that?

Perhaps Davide has some thought to offer here?



-- 
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: epoll(7) redux

[Davide Libenzi]

On Wed, 9 Apr 2008, Michael Kerrisk wrote:

> On Wed, Apr 9, 2008 at 1:07 PM, Sam Varshavchik <mrsam-W1w4QoW4mIDgLSHwZvcCBg@public.gmane.org> wrote:
> > Q2
> >
> >   Can two epoll sets wait for the same file descriptor? If so, are events
> > reported to both epoll file descriptors?
> >
> > A2
> >
> >   Yes, and events would be reported to both. However, it is not recommended.
> >
> > =========
> >
> > It's not clear what "not recommended" means. Furthermore, I don't think
> > there's anything wrong with two epoll file descriptors waiting for different
> > events on the same file descriptor. One's waiting for POLLIN, the other for
> > POLLOUT. What's wrong with that?
> 
> Perhaps Davide has some thought to offer here?

You can do it. No problem as far as epoll goes. The "recommended" bit was 
more because it is very easy to get things wrong from an application 
perspective POV, when doing that.
In the case above, first POLLOUT is "almost" always signaled, so you'll 
receive continuous events over there. Second, if both events shows up at 
the same time (say in two different threads) and you do not take care of 
it, you'll end up handling the same fd, at the same time, in two different 
threads.
*Many* users got this wrong, so *many* times, that the "not recommended" 
is the least warning we can issue.



- Davide


--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: epoll(7) redux

[Sam Varshavchik]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

Davide Libenzi writes:

> On Wed, 9 Apr 2008, Michael Kerrisk wrote:
> 
>> On Wed, Apr 9, 2008 at 1:07 PM, Sam Varshavchik <mrsam-W1w4QoW4mIDgLSHwZvcCBg@public.gmane.org> wrote:
>> > Q2
>> >
>> >   Can two epoll sets wait for the same file descriptor? If so, are events
>> > reported to both epoll file descriptors?
>> >
>> > A2
>> >
>> >   Yes, and events would be reported to both. However, it is not recommended.
>> >
>> > =========
>> >
>> > It's not clear what "not recommended" means. Furthermore, I don't think
>> > there's anything wrong with two epoll file descriptors waiting for different
>> > events on the same file descriptor. One's waiting for POLLIN, the other for
>> > POLLOUT. What's wrong with that?
>> 
>> Perhaps Davide has some thought to offer here?
> 
> You can do it. No problem as far as epoll goes. The "recommended" bit was 
> more because it is very easy to get things wrong from an application 
> perspective POV, when doing that.
> In the case above, first POLLOUT is "almost" always signaled, so you'll 
> receive continuous events over there. Second, if both events shows up at 
> the same time (say in two different threads) and you do not take care of 
> it, you'll end up handling the same fd, at the same time, in two different 
> threads.

That's what I had in mind. One thread has the fd in its epoll fd for POLLIN, 
and handles the read aspect of it. Another thread puts the fd into a 
different epoll fd, for POLLOUT, and handles the writing aspect of it. It 
shouldn't be too difficult for both threads to correctly implement their 
corresponding semantics.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: epoll(7) redux

[Michael Kerrisk]

Sam Varshavchik wrote:
> Davide Libenzi writes:
> 
>> On Wed, 9 Apr 2008, Michael Kerrisk wrote:
>>
>>> On Wed, Apr 9, 2008 at 1:07 PM, Sam Varshavchik
>>> <mrsam-W1w4QoW4mIDgLSHwZvcCBg@public.gmane.org> wrote:
>>> > Q2
>>> >
>>> >   Can two epoll sets wait for the same file descriptor? If so, are
>>> events
>>> > reported to both epoll file descriptors?
>>> >
>>> > A2
>>> >
>>> >   Yes, and events would be reported to both. However, it is not
>>> recommended.
>>> >
>>> > =========
>>> >
>>> > It's not clear what "not recommended" means. Furthermore, I don't
>>> think
>>> > there's anything wrong with two epoll file descriptors waiting for
>>> different
>>> > events on the same file descriptor. One's waiting for POLLIN, the
>>> other for
>>> > POLLOUT. What's wrong with that?
>>>
>>> Perhaps Davide has some thought to offer here?
>>
>> You can do it. No problem as far as epoll goes. The "recommended" bit
>> was more because it is very easy to get things wrong from an
>> application perspective POV, when doing that.
>> In the case above, first POLLOUT is "almost" always signaled, so
>> you'll receive continuous events over there. Second, if both events
>> shows up at the same time (say in two different threads) and you do
>> not take care of it, you'll end up handling the same fd, at the same
>> time, in two different threads.
> 
> That's what I had in mind. One thread has the fd in its epoll fd for
> POLLIN, and handles the read aspect of it. Another thread puts the fd
> into a different epoll fd, for POLLOUT, and handles the writing aspect
> of it. It shouldn't be too difficult for both threads to correctly
> implement their corresponding semantics.


So how about I change:

A2. Yes, and events would be reported to both. However, it is
not recommended.

to:

Yes, and events would be reported to both. However, careful programming
may be needed to do this correctly.

?

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: epoll(7) redux

[Davide Libenzi]

On Wed, 21 May 2008, Michael Kerrisk wrote:

> 
> 
> Sam Varshavchik wrote:
> > Davide Libenzi writes:
> > 
> >> On Wed, 9 Apr 2008, Michael Kerrisk wrote:
> >>
> >>> On Wed, Apr 9, 2008 at 1:07 PM, Sam Varshavchik
> >>> <mrsam-W1w4QoW4mIDgLSHwZvcCBg@public.gmane.org> wrote:
> >>> > Q2
> >>> >
> >>> >   Can two epoll sets wait for the same file descriptor? If so, are
> >>> events
> >>> > reported to both epoll file descriptors?
> >>> >
> >>> > A2
> >>> >
> >>> >   Yes, and events would be reported to both. However, it is not
> >>> recommended.
> >>> >
> >>> > =========
> >>> >
> >>> > It's not clear what "not recommended" means. Furthermore, I don't
> >>> think
> >>> > there's anything wrong with two epoll file descriptors waiting for
> >>> different
> >>> > events on the same file descriptor. One's waiting for POLLIN, the
> >>> other for
> >>> > POLLOUT. What's wrong with that?
> >>>
> >>> Perhaps Davide has some thought to offer here?
> >>
> >> You can do it. No problem as far as epoll goes. The "recommended" bit
> >> was more because it is very easy to get things wrong from an
> >> application perspective POV, when doing that.
> >> In the case above, first POLLOUT is "almost" always signaled, so
> >> you'll receive continuous events over there. Second, if both events
> >> shows up at the same time (say in two different threads) and you do
> >> not take care of it, you'll end up handling the same fd, at the same
> >> time, in two different threads.
> > 
> > That's what I had in mind. One thread has the fd in its epoll fd for
> > POLLIN, and handles the read aspect of it. Another thread puts the fd
> > into a different epoll fd, for POLLOUT, and handles the writing aspect
> > of it. It shouldn't be too difficult for both threads to correctly
> > implement their corresponding semantics.
> 
> 
> So how about I change:
> 
> A2. Yes, and events would be reported to both. However, it is
> not recommended.
> 
> to:
> 
> Yes, and events would be reported to both. However, careful programming
> may be needed to do this correctly.
> 
> ?

Looks OK to me.



- Davide


--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html