From: Slawomir L. on
Hello All,

I have a question regarding use of epoll in edge-triggered mode.

In my program, the epoll notifies me of pending data arriving at a
non-blocking TCP socket. I proceed to read from the socket, passing it
buffer of some length. Now, if the number of bytes returned from
read(..) was _less_ than provided buffer length, is it correct to assume
the edge has been reset?

Basically, I'm trying to determine if I'm required to keep calling
read(..) until I explicitly get EWOULDBLOCK to assume the edge was reset.

Thanks,
Slaw





From: Rainer Weikusat on
"Slawomir L." <sl(a)paramay.com> writes:
> I have a question regarding use of epoll in edge-triggered mode.
>
> In my program, the epoll notifies me of pending data arriving at a
> non-blocking TCP socket. I proceed to read from the socket, passing it
> buffer of some length. Now, if the number of bytes returned from
> read(..) was _less_ than provided buffer length, is it correct to
> assume the edge has been reset?
>
> Basically, I'm trying to determine if I'm required to keep calling
> read(..) until I explicitly get EWOULDBLOCK to assume the edge was
> reset.

Have you considered to read the epoll-manpage?

Q9 Do I need to continuously read/write a file descriptor
until EAGAIN when using the EPOLLET flag (edge-triggered
behavior) ?

A9 Receiving an event from epoll_wait(2) should suggest to
you that such file descriptor is ready for the requested I/O
operation. You must consider it ready until the next
(non-blocking) read/write yields EAGAIN. When and how you
will use the file descriptor is entirely up to you.

For packet/token-oriented files (e.g., datagram socket,
terminal in canonical mode), the only way to detect the end
of the read/write I/O space is to continue to
read/write until EAGAIN.

For stream-oriented files (e.g., pipe, FIFO, stream
socket), the condition that the read/write I/O space is
exhausted can also be detected by checking the amount
of data read from / written 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 of having exhausted the
read I/O space for the file descriptor. The same is true
when writing using write(2). (Avoid this latter
technique if you cannot guarantee that the monitored file
descriptor always refers to a stream-oriented file.)
[epoll(2), 'Questions and Answers]

I would nevertheless usually rather read until I get EAGAIN. Assuming
that some amount of time is spent processing the data which was read,
additional input could have arrived meanwhile.
From: Slawomir L. on
On 06/23/2010 10:40 AM, Rainer Weikusat wrote:
> Have you considered to read the epoll-manpage?

Of course.

> A9 Receiving an event from epoll_wait(2) should suggest to
> you that such file descriptor is ready for the requested I/O
> operation. You must consider it ready until the next
> (non-blocking) read/write yields EAGAIN.

One could avoid an extra system call if "bytes_received < buffer_length"
indicated edge got reset.

> I would nevertheless usually rather read until I get EAGAIN. Assuming
> that some amount of time is spent processing the data which was read,
> additional input could have arrived meanwhile.

a) amount of time spent in processing should have nothing to do with
edge reset status -- it's ether reset or not.

b) if reading a man-page makes you "nevertheless usually rather" do
something, you probably find it inconclusive. Similarly, it prompted my
original post.
From: John Kelly on
On Wed, 23 Jun 2010 10:49:57 -0500, "Slawomir L." <sl(a)paramay.com>
wrote:

>if reading a man-page makes you "nevertheless usually rather" do
>something, you probably find it inconclusive.

Without pompous bombast what would usenet be.


--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php

From: Rainer Weikusat on
"Slawomir L." <sl(a)paramay.com> writes:
> On 06/23/2010 10:40 AM, Rainer Weikusat wrote:
>> Have you considered to read the epoll-manpage?
>
> Of course.
>
>> A9 Receiving an event from epoll_wait(2) should suggest to
>> you that such file descriptor is ready for the requested I/O
>> operation. You must consider it ready until the next
>> (non-blocking) read/write yields EAGAIN.
>
> One could avoid an extra system call if "bytes_received <
> buffer_length" indicated edge got reset.

RTFM.