[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] error handling



On Mon, Oct 26, 2009 at 06:23:04PM -0500, Kathryn Hogg wrote:
> I'm a new libevent user.

Hello, and welcome!

>                         I have some pretty old code with select() at the
> heart of its mainloop.  We're running issues with the number of fd's in an
> fd_set on some platform.  I decided to use libevent since it abstracts
> away using the whatever methods are available on different platforms.
> 
> How do we do error handling in the dispatch family of functions?  For
> example, lets say that event_loop() returns -1 and errno is EBADF?  How do
> I figure out which fd is bad?  Can I get a list of all the registered
> events?

You can dump this list to a file (like stdout or stderr) with
event_base_dump_events(), but there isn't (currently) a good way to
access it via the API.

Generally, it's a bad sign if you're getting EBADF with select at all:
It usually a sign that you closed the file descriptor without deleting
the corresponding event.  This usually isn't an error you should try
to react to so much as a problem in your program.  (It's hard to write
portable code that relies on this behavior, since the different
OS backends handle closed sockets differently.  Some will complain;
some won't.)

You could try debugging this by:

  * Add a check before every time you close a socket to make sure that
    the corresponding event is not pending.  (The event_pending call
    tells you if an event is pending.)

  * Looking through the code to look for places where fd lifetime does
    not match event lifetime.

  * If you want to be paranoid about these things, remember that it is
    always safe to event_del() any event that you have created with
    event_set()/event_assign()/event_new(), even if that event has
    already been passed to event_del().  So adding some extra
    event_del() calls might not be out of order.

				* * *

That said, I'm thinking that somebody should add a "debug mode" to the
Libevent-2.0.x series.  During development, there are plenty of times
when it's helpful to trade a couple percent of execution speed for
accurate information about what's going wrong.

I'd like some feedback about what kinds of hard-to-debug situations
people _currently_ run into.  So far, I've got the following:

 * "I'm about to close a file descriptor and want to know whether I
    remembered to delete all the events watching it."  [This thread.]

 * "My OS spat a error back at me, and I'd like Libevent to spend a
   little time figuring out why."  [This thread.]

 * "I want Libevent to iterate over all the fds it knows about and
   make sure that none have been closed." [This thread.]

 * "I added an event, then I forgot to delete it before I called
   event_set()/event_assign() on the memory again, and then I added it
   again."  [The "infinity loop" thread from earlier this month.]

For this purpose, I am way more interested in actual problems people
have seen in some program than in theoretical ones, but I'd be
interested in hearing about both.

yrs,
-- 
Nick Mathewson

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.