Re: [Libevent-users] event_base_dispatch returning -1 - help debugging

[Dave Hart <davehart@xxxxxxxxx>]

On Tue, Jun 12, 2012 at 4:47 PM, Julian Bui <julianbui@xxxxxxxxx> wrote:
> Thanks for the quick response, Nick.
>
>>  Step one might be to build with debugging support
>
> Ah, I didn't realize debugging required you to build with support for it.
>
> I am using windows and have built with just `nmake` in visual studio.  What
> is the preferred method of building in windows?  When I use the visual
> studio command line, I cannot seem to use configure.  `configure`  and
> `configure --enable-debug-mode` show "is not recognized as an internal or
> external command, operable program or batch file"

configure scripts generally don't work on Windows.  If you search
configure.ac for debug-mode you should find the snippet that handles
that option.  On systems where configure works, the resulting
selection is enacted by a #define in config.h.  If you arrange for the
same #define to be in place for libevent and your code, you'll get the
same debugging-capable libevent.

>> A select() failure seems likelier
>
> I think I might possibly be misunderstanding the usage of libevent.  I
> thought libevent abstracts away the select mechanism so I don't have to deal
> with it.  When I was looking at example code, they never once had to deal
> with the underlying mechanism like select().  Could you possibly comment on
> this?  What is the general strategy/structure/architecture of a program if I
> am to use both libevent and select()?  Is there any example code that shows
> this interaction?

You're misunderstanding Nick's response.  He's trying to find the root
cause of the failure, which necessarily means looking inside the
libevent "black box" to its implementation.  libevent's async I/O
abstraction is imperfect and steadily improving, recently due in great
part to Nick's workmanlike efforts.  Nick is a great resource and I
recommend you use him sparingly -- to help guide your investigation
into your problem, and assist if needed in crafting a suitable fix
once the failure is understood.

More often than not, Nick's patient "customer service" of programmers
with libevent issues reveals no obvious improvement needed in the
libevent code, though sometimes highlighting need for better
documentation, which he's also been tackling.  Still, while I'm sure
his assistance is valued by those he helps, in terms of the libevent
project, Nick's talents are underutilized compared to situations where
libevent bugs are exposed and corrected.

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