From: Robert Hancock <hancockr@shaw.ca>
To: Michael Noisternig <mnoist@cosy.sbg.ac.at>
Cc: linux-kernel@vger.kernel.org
Subject: Re: (more) epoll troubles
Date: Mon, 01 Sep 2008 11:32:54 -0600 [thread overview]
Message-ID: <48BC2746.1090006@shaw.ca> (raw)
In-Reply-To: <48BC26D9.1040300@shaw.ca>
Robert Hancock wrote:
> Michael Noisternig wrote:
>> Hello,
>>
>> and sorry again if this is the wrong place to ask (again, please hint
>> to me to an appropriate place to ask in that case).
>>
>> After experimenting with epoll edge-triggered mode I am clueless why
>> on a few occassions I seem to not get any input notification despite
>> data is available.
>>
>> In detail: I have set up sockets with epoll events
>> EPOLLET|EPOLLRDHUP|EPOLLIN. When I get EPOLLIN for a socket, I read()
>> as long as I get what I asked for, i.e. whenever read() returns either
>> EAGAIN or less data than I asked for I take this as indication that I
>> must wait for another EPOLLIN notification. However, this does not
>> seem to work always.
>>
>> Here is some log from my program:
>>
>> 0x9e6b8a8: read not avail (1460/2048 read)
>> i.e. tried to read 2048 bytes, got 1460 -> assume must wait for
>> EPOLLIN for more data to read
>> (note that the fd is always in the epoll set with
>> EPOLLET|EPOLLRDHUP|EPOLLIN)
>
> It would likely be better to always continue trying to read until EAGAIN
> is returned, even if the read returned less than the requested amount,
> as implied here:
>
> http://linux.die.net/man/7/epoll
>
> "The function do_use_fd() uses the new ready file descriptor until
> EAGAIN is returned by either read(2) or write(2). An event driven state
> machine application should, after having received EAGAIN, record its
> current state so that at the next call to do_use_fd() it will continue
> to read(2) or write(2) from where it stopped before. "
Though, this is somewhat contradicted by the FAQ section:
"the condition that the read/write I/O space is exhausted can be
detected by checking the amount of data read/write from/to the target
file descriptor. For example, if you call read(2) by asking to read a
certain amount of data and read(2) returns a lower number of bytes, you
can be sure to have exhausted the read I/O space for such file descriptor."
next prev parent reply other threads:[~2008-09-01 17:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.zt4K08zThcs3bS6QJSiWmdw4amQ@ifi.uio.no>
2008-09-01 17:31 ` (more) epoll troubles Robert Hancock
2008-09-01 17:32 ` Robert Hancock [this message]
2008-09-01 18:29 ` Michael Noisternig
2008-09-01 18:46 ` Davide Libenzi
2008-08-31 13:38 Michael Noisternig
2008-09-03 5:57 ` Andrew Morton
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=48BC2746.1090006@shaw.ca \
--to=hancockr@shaw.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=mnoist@cosy.sbg.ac.at \
/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