Oh, one more thing.  I would really like to verify that there is indeed an
event still pending - because I can at least restart the dispatch loop if
there is an event pending.  But I have not been able to correctly use
event_pending for some reason.  My code is below and it always prints
"event is not pending" regardless of whether or not the dispatch loop is
running.  The code sets up a persistent event that will handle every
incoming connection to my server.  I would expect that at some point it
would print out that the event is pending...because like I said, this code
DOES work most of the time, and if it's not pending I have no idea why the
handlers would even still be triggered.

struct event* my_event = event_new(s_event_base, server_socket, EV_READ |
EV_PERSIST, &TileSocketServer::onAccept, (void*) client);

      if(my_event != NULL)
      {
         int add_err = event_add(my_event, NULL);

         if(add_err != 0)
            cout << "add_err:" << add_err << endl;

         int is_evt_pending = event_pending(my_event, EV_READ | EV_PERSIST,
NULL);
         if(is_evt_pending == 1)
         {
            cout << "event is still pending" << endl;
         }
         else
         {
            cout << "event is still pending" << endl;
         }



On Tue, Jun 12, 2012 at 9:47 AM, Julian Bui <julian...@gmail.com> 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"
>
> > 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?
>
> Please let me know.
>
> Thanks for all your help
> -Julian
>
>
> On Fri, Jun 8, 2012 at 1:10 PM, Nick Mathewson <ni...@freehaven.net>wrote:
>
>> On Thu, Jun 7, 2012 at 4:59 PM, Julian Bui <julian...@gmail.com> wrote:
>> > Hi everyone,
>> >
>> > I am having trouble with my libevent 2.0.18 server.  The dispatch loop
>> keeps
>> > returning -1 and I cannot determine the cause.
>> >
>> > I have not tried searching the mailing list as there does not seem to
>> be a
>> > search option (http://archives.seul.org/libevent/users/)
>>
>> Step one might be to build with debugging support and try that log
>> trick again, with debugging logs enabled; that might shed some light
>> on what's going on.
>>
>> It sounds (Based on your mention of WSAGetLastError()) like you're
>> using windows here.  The only ways that I can see for win32select's
>> win32_dispatch functino to return -1 are if select() returns -1, or
>> realloc returns -1.
>>
>> A select() failure seems likelier.  You could set a debugging
>> tracepoint at the part of win32_dispatch that says:
>>   if (res <= 0) {
>>      return res;
>>   }
>> and see if it ever returns with res = -1, and if so what the value of
>> WSAGetLastError is.  Or you could insert a printf there if you don't
>> want to mess with the debugger.
>>
>> Do any of the error codes in the documentation for select() seem
>> plausible to you?  The likeliest one as far as I can tell is that
>> there is a nonexistent (or no-longer-existent) socket still in the
>> list of sockets that select() is looking at.
>> ***********************************************************************
>> To unsubscribe, send an e-mail to majord...@freehaven.net with
>> unsubscribe libevent-users    in the body.
>>
>
>

Reply via email to