Hi! Thanks for your answer! Sorry about the mix-up with example. That definitely didn't help getting my question across ;-).
What actually my problem is is that libevent gives me an EAGAIN error in a connection listener (callback) when running on SmartOS (ie. Solaris). And I was wondering if that was normal? As far as I can tell the documentation for suchs listeners is specified "A callback that we invoke when a listener encounters a non-retriable error.". Hence the inquiry whether I as user of libevent should be able to handle EGAIN? The documentation seems to imply I should only be getting fatal errors, not something like EGAIN? I'm actually running libevent with 'EVENT_NOEVPORT=yes' because I encountered an situation in which libevent seems to be getting in an unbound loop and starts consuming 100% CPU. But thats not related I think (and something I will delve in later) to the more conceptual question on how and where to deal with EAGAIN. Kind regards, Jasper Siepkes > On 24 juni 2019 at 15:36 Azat Khuzhin <[email protected]> wrote: > > > On Fri, Jun 21, 2019 at 5:22 PM Jasper Siepkes <[email protected]> > wrote: > > > > Hi! > > > > I'm a bit confused about how libevent looks at EAGAIN. From what I can tell > > is that some event base implementations deal with EAGAIN themselves and > > will never return EAGAIN as an error. However other backends do seem to > > return EAGAIN as an error. The "A low-level ROT13 server with Libevent" > > example on http://www.wangafu.net/~nickm/libevent-book/01_intro.html seems > > to take into account libevent could return EAGAIN but from what I can tell > > that documentation might be a bit dated? > > > > Should I as a developer always consider that EAGAIN might be returned? Or > > should it never be returned by libevent and be handled in the event base? > > Hi! > > libevent allows you to avoid busy polling (via epoll/poll/select/...) > > That example uses only event (without bufferevent), and with this you > still need to call read(2) by yourself, and of course it can return > EAGAIN. > > But if you use bufferevent, you do not need to call read() manually > since they contains two buffers: input and output, that you can use > instead of plain read(2)/write(2). > > Hope this helps, > Azat. > *********************************************************************** > To unsubscribe, send an e-mail to [email protected] with > unsubscribe libevent-users in the body. *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
