On Mon, Oct 23, 2006, William Ahern wrote: > > >From my reading of the kqueue code this isn't the case. > > The change is 'bundled up' into the 'changes' array and kept there > > until the next call to kq_dispatch(). > > > > Yet another reason why kqueue is superior to epoll? ;)
kqueue has a lot of fruit which noone really seems to be using. Stuff like EOF signalling (There's an #ifdef inside the libevent code which conditionally uses it), socket error reporting and being told about the accept() queue depth and read/write buffer sizes. So you can avoid the extra read/write to receive EOF-ness (ie, read event w/ size=0 I think; watching for EV_EOF), can 'grow' or allocate receive buffers based on how much data is there; can choose how big your writev() can be based on how much space there is in the write socket buffer, etc. I'm still fiddling around with this to see if there's any tangible benefit. Adrian _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
