[Libevent-users] [PATCH] test/Makefile.am: Correct a relative path issue

[Christopher Layne]

1. event_rpcgen.py will fail to open regress.rpc if building outside the source
directory.

-cl

--

Index: Makefile.am
===
--- Makefile.am (revision 433)
+++ Makefile.am (working copy)
@@ -18,7 +18,7 @@
 bench_SOURCES = bench.c
 
 regress.gen.c regress.gen.h: regress.rpc
-   $(top_srcdir)/event_rpcgen.py regress.rpc || echo No Python installed
+   $(top_srcdir)/event_rpcgen.py ${srcdir}/regress.rpc || echo No Python 
installed
 
 DISTCLEANFILES = *~
 CLEANFILES = regress.gen.h regress.gen.c
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

Re: [Libevent-users] event_add() failure return handling

[M.H.VanLeeuwen]

Christopher Layne wrote:

On Tue, Sep 18, 2007 at 10:10:42PM -0500, M.H.VanLeeuwen wrote:
  

Hi,

When event_add(ev, tv) returns -1, what is the proper way to clean up.

For example function XYZZY() takes socket fd as an argument

XYZZY(int sockfd)
{
allocate event structure related memory...
...
  event_set((event-event), sockfd, EV_TIMEOUT | EV_WRITE | 
EV_PERSIST, connected, (event-event));

  ret = event_base_set(event_base, (event-event));

  if (ret == 0)
  {
  ret = event_add((event-event), CONNECT_WAIT);
  }

 if (ret != 0)
 {
// What is the proper action to take here?
return FAIL;
  }
...
 return SUCCESS;
}



The only way to receive a non-zero retval from event_add is if the
underlying event notification mechanism returns a non-zero value
to event_add. In order to determine which event mechanism that is,
we need more information like which OS you're experiencing this under
and/or the particular event mechanism you're using (set the following
shell variable before executing your code: EVENT_SHOW_METHOD=1).

Without knowing more than that all one can say is that if event_add()
returns -1, it is programming error, somewhere. I speculate possibly
your fd is invalid or previously closed or something else is wrong.

  

Hi Chris,

Linux 2.6 kernel, on _rare_ occasions I get errno=2 back from epoll_add().
#define ENOENT2  /* No such file or directory */

I'd have expected EBADF (9) if the sockfd was invalid.

I've not gone to look at why this is being returned yet, any ideas?

So the question really is, does one need to call event_del() to cleanup
or should the event_add() cleanup the timer before returning an error?
The change/fix seems simple enough.

Agreed, the occurrence is quite rare indeed, and likely a bug in my code.

Thanks,
Martin
The reason I ask is that it seems event_add() will continue to time for 
CONNECT_WAIT time
even if it returns -1, failure.  Shouldn't event_add(), on return of -1, 
unwind from the timer that

it has started?



This is valid. However it's kind of a rare case.

-cl
  


___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users

[Libevent-users] event_base_loop_break()?

[Scott Lamb]

While playing with pyevent, I saw this code:

def abort():
Abort event dispatch loop.
cdef extern int event_gotsig
cdef extern int (*event_sigcb)()
event_sigcb = __event_sigcb
event_gotsig = 1

This is used in exception handling - if a callback throws an exception, 
it does this to propogate the exception through immediately (breaking 
out of the loop without running any more callbacks).


This off-label use of a deprecated libevent interface is confusing, and 
I suspect it can interact badly with the more modern signal handling 
interface.


I propose instead that libevent have a event_base_loop_break() and 
event_loop_break(). (Or whatever you want them called.) They'd differ 
from event_{base_,}loop_exit() in that they would *immediately* abort 
the loop without finishing the iteration (i.e., sooner than 
event_base_loop_exit({.tv_sec=0, .tv_usec=0})). They'd be analogous to 
the C break; statement. Like event_loop_exit(), the next dispatch 
would be unaffected.


Feelings? I'd be happy to work up a patch and unit test.

Best regards,
Scott

[1] - Well, not quite, because there's a bug. 
http://code.google.com/p/pyevent/issues/detail?id=6 But it's clearly 
intended to, and with a small patch it does.


--
Scott Lamb http://www.slamb.org/
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users