From: Slawomir L. on 23 Jun 2010 11:29 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 23 Jun 2010 11:40 "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 23 Jun 2010 11:49 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 23 Jun 2010 11:58 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 23 Jun 2010 11:58 "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.
|
Next
|
Last
Pages: 1 2 Prev: Fueling your car with natural gas from home Next: Where do I find Xlib.h in freebsd?? |