Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups: comp.os.linux.development.apps
Subject: Re: Strange EPOLLOUT|EPOLLET behaviour (spurious events)
Date: Wed, 25 Apr 2012 23:11:51 +0100
Lines: 34
Message-ID: <87ehrbmpg8.fsf@sapphire.mobileactivedefense.com>
References: <slrnjpgo5a.q7.cmeerw@msgid.cmeerw.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: individual.net 363Z3wrngbgQbXxfxuWolASeH7GNoCDXBoiPH07V/zwVXYM5s=
Cancel-Lock: sha1:b6KeVrcngBJPvOUOKO6J/tWxP8U= sha1:e0CmTon74Myg7XGjmCFVdC6pFE0=
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Xref: csiph.com comp.os.linux.development.apps:472

Christof Meerwald <NOSPAM-seeMySig+uyk5+@usenet.cmeerw.org> writes:
> I am seeing some unexpected behaviour with EPOLLOUT in edge-triggered
> mode - some example code is available from
> http://svn.cmeerw.net/src/nginetd/trunk/test/eptest-out.c
>
> What seems to be happening is that I get an EPOLLOUT event after each
> send on the socket (even in edge-triggered mode). This is what strace
> shows me:

[...]

> But as I am using EPOLLET, I wouldn't expect to get any EPOLLOUT
> events on that socket as send never returns EAGAIN (and there isn't
> any state transition).

That's expected behaviour: You get EPOLLOUT as soon as 'a send
operation' completed. You will also get EPOLLIN whenever the state
transitions from 'buffer empty' to 'buffer not empty' irregardless of
read ever returning EAGAIN. The kernel doesn't keep track of which
state changes where communicated to a userspace application. If this
is a problem, you should initially have all notifications disabled and
only enable them after 'something failed with EAGAIN'. It is necessary
to be somewhat careful in this cases so that state transitions aren't
lost. In pseudo-code, the logic could look like this:

	1. perform operation
        2. EAGAIN? if not, goto done
        3. enable event
        4. perform operation again
        5. EAGAIN? if yes, goto 'wait for notification'
        6. disable event
        7. done

This may, of course, result in lots and lots of epoll_ctl calls ...