Re: [Libevent-users] Should my code be able to deal with EAGAIN?

[Jasper Siepkes <siepkes@xxxxxxxxxxxxxxxx>]

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 <azat@xxxxxxxxxxxx> wrote:
> 
> 
> On Fri, Jun 21, 2019 at 5:22 PM Jasper Siepkes <siepkes@xxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.