On Wed, Dec 05, 2012 at 07:28:25PM +0000, Alexander Kolbasov wrote: > On Dec 5, 2012, at 7:32 AM, Mark Ellzey wrote: > > > On Wed, Dec 05, 2012 at 11:10:04AM +0200, Nir Soffer wrote: > >> On Wed, Dec 5, 2012 at 10:54 AM, Sashan Govender <sash...@gmail.com> wrote: > >> > >>> Hi! > >>> > >>> > >>>> 1) I don't see any notion of event notification on FD exception - e.g. > >>>> socket close. > >>>> There are some words for buffer events, but nothing for regular file > >>>> descriptor based callbacks. So what is a good way to get a callback > >>>> when specific > >>>> FD is closed/disconnected? > >>>> > >>> > >>> If the fd is a socket and the peer closes then you'll get a read callback. > >>> When you read from the fd 'read' will return 0 indicating that the peer > >>> closed. > >>> > >> > >> But if the peer die without closing the socket, you will never get a read > >> event. In this case you will fail when writing to the socket. > >> > >> You can simulate this by disconnecting the peer from the network. > > > > Writing to the socket, in most cases, not something you want to do just > > to determine if the socket is alive. > > > > If a peer is disconnected, e.g., it shuts down, the OS *should* > > eventually time-out the session which will result in your eventcb being > > executed. > > > > Another option is to set your own read timeout on the socket. > > Does it mean that peer close is not triggering EV_READ callback and the user > should > periodically timeout and attempt reads and check for read errors? >
Depends on what you mean by peer-closed. I think in this thread we were speaking about the situation where a client never sends a RST/FIN, i.e., the client host is shut down during transmission. If you set a read timeout via libevent or the OS times the connection out, the event callback, not the read callback is executed. *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.