Re: [Libevent-users] [PATCH] signal.c: debug cleanups
Thank you. Applied to trunk and branch.
Niels
On Nov 10, 2007 5:46 PM, Christopher Layne [EMAIL PROTECTED] wrote:
1. Fix a debugging call with wrong format, (we should probably use
__attr__((format(printf))) eventually).
2. Add additional debugging calls for sanity.
-cl
Index: signal.c
===
--- signal.c(revision 507)
+++ signal.c(working copy)
@@ -141,7 +141,7 @@
* a dynamic array is used to keep footprint on the low side.
*/
if (evsignal = sig-sh_old_max) {
- event_debug((%s: evsignal sh_old_max, resizing array,
+ event_debug((%s: evsignal (%d) = sh_old_max (%d), resizing,
__func__, evsignal, sig-sh_old_max));
sig-sh_old_max = evsignal + 1;
p = realloc(sig-sh_old, sig-sh_old_max * sizeof
*sig-sh_old);
@@ -159,8 +159,9 @@
return (-1);
}
+ /* setup new handler */
+ event_debug((%s: %p: changing signal handler, __func__, ev));
#ifdef HAVE_SIGACTION
- /* setup new handler */
memset(sa, 0, sizeof(sa));
sa.sa_handler = evsignal_handler;
sa.sa_flags |= SA_RESTART;
@@ -207,6 +208,7 @@
evsignal = EVENT_SIGNAL(ev);
/* restore previous handler */
+ event_debug((%s: %p: restoring signal handler, __func__, ev));
sh = sig-sh_old[evsignal];
sig-sh_old[evsignal] = NULL;
#ifdef HAVE_SIGACTION
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libev-1.3e beta release
Hi,
On Mon 12.11.2007 02:54, Marc Lehmann wrote:
Over the last few days, I took all of your feedback that arrived in
time or was actable upon and updated libev.
Its available at http://dist.schmorp.de/libev/libev-1.3e.tar.gz
Nice lib, I prefer to have a own list for this lib, jm2c.
When you call test.sh in the test dir you will find that your lib shows
me:
KQUEUE
test-eof: OKAY
.
.
.
DEVPOLL
test-eof: OKAY
.
.
.
on:
Linux 2.6.22 #1 SMP Mon Nov 12 08:58:18 CET 2007 i686 Intel(R) Core(TM)2
CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
Which looks very cool but wrong. this is the output of libevent:
---
Running tests:
KQUEUE
Skipping test
DEVPOLL
Skipping test
POLL
test-eof: OKAY
.
.
.
---
The reason for this could be:
---event.c
.
.
.
#ifdef HAVE_EVENT_PORTS
extern const struct eventop evportops;
#endif
#ifdef HAVE_SELECT
extern const struct eventop selectops;
#endif
#ifdef HAVE_POLL
extern const struct eventop pollops;
#endif
#ifdef HAVE_EPOLL
extern const struct eventop epollops;
#endif
#ifdef HAVE_WORKING_KQUEUE
extern const struct eventop kqops;
#endif
#ifdef HAVE_DEVPOLL
extern const struct eventop devpollops;
#endif
#ifdef WIN32
extern const struct eventop win32ops;
#endif
.
.
.
/* In order of preference */
const struct eventop *eventops[] = {
#ifdef HAVE_EVENT_PORTS
evportops,
#endif
#ifdef HAVE_WORKING_KQUEUE
kqops,
#endif
#ifdef HAVE_EPOLL
epollops,
#endif
#ifdef HAVE_DEVPOLL
devpollops,
#endif
#ifdef HAVE_POLL
pollops,
#endif
#ifdef HAVE_SELECT
selectops,
#endif
#ifdef WIN32
win32ops,
#endif
NULL
};
.
.
.
.
event_init(){
.
.
.
base-evbase = NULL;
for (i = 0; eventops[i] !base-evbase; i++) {
base-evsel = eventops[i];
base-evbase = base-evsel-init(base);
}
}
---
It would be nice to have such a similar behaviour in libev ;-)
It would also be nice to have similar samples for libev as they exists
for libevent compatibility mode, eg. in samples or test dir.
Cheers
Aleks
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
[Libevent-users] libevent vs libev
As a casual user of libevent and occasional reader of this mailing list, I have a few questions: 1. What is this libev library? 2. How does it differ from libevent? Which is recommended for general usage on Linux? 3. If it is a separate library, why is it being discussed on the libevent mailing list? Shouldn't there be a separate list for this (libev-users)? Niels et all, great work on the 1.4.0 release -- especially the separate libraries and doxygen documentation. Thanks. Larry ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] libevent vs libev
On Tue, Nov 13, 2007 at 01:53:33PM -0800, Larry Lewis [EMAIL PROTECTED] wrote: 1. What is this libev library? Its a drop-in replacement for libevent. While it provides a libevent emulation API, it also has a new api that fixes most (maybe all) of the actual and perceived api problems with libevent. It is also faster, at least with epoll and timers being involved, uses less memory etc. etc. Benchmark and documentation is currently linked from here: http://libev.schmorp.de/ 2. How does it differ from libevent? It offers a completely new, incompatible API with different design goals but also emulates libevent, at leats its event core parts. It is also easily embeddable for those people who need this functionality and wildly configurable. It does not feature evbuffer, evtags, evhttp or evdns, but the libevent source files implementing those can be used without any changes with libev. In fact, the only release file so far is actually a libevent tarball patched by replacing the libevent event handling with the libev files and keeping all else. The high degree of compatibility also makes it trivial to do the same for any upcoming 1.4 release. Which is recommended for general usage on Linux? Decidedly both of them, depending on your goal and needs: - libevent has seen vastly more testing than libev (especially outside linux, which should always be an option). - libev has a much more efficient epoll implementation, and much faster timers, and less arbitrary limitations (as in the type of combinations of fd events are allowed etc.) - libevent isn't embeddable, libev is - libevent is 100% compatible to libevent, libev isn't, only emulating the most visible parts - if libevent works fine for you, its a safe, available fallback - if the libev api appeals to you more than the libevent api, its the way to go. etc. etc. If libevent works for you, you could try out libev, too, using its emulation API. In fact, when you keep developing for libevent you lose nothing, as you can use either library as you want. 3. If it is a separate library, why is it being discussed on the libevent mailing list? Shouldn't there be a separate list for this (libev-users)? The plan by both the libev developer (me) and the libevent maintainers at the moment is to integrate libev (ideas, parts, or full) into libevent, which makes it on-topic on libevent. Also, the new API was developed together with the existing libevent users, as libev does not (at the moment) compete as a separate product or solution, but is aimed at providing a better libevent for the future. If this plan dies, then it would be more than appropriate to move discussions to another mailinglist, as libevent would then not progress towards the better API developed here but instead keep its interface, and discussions about changes would not belong on this mailinglist anymore (as in the past). On the other hand, most of the design is finished by now, and so the amount of discussion has gone down quite a bit. Let me thank the libevent users again here for helping me design the new API, all your input was very important. Niels et all, great work on the 1.4.0 release -- especially the separate libraries and doxygen documentation. Hmm.. is 1.4.0 even released yet? I only see the beta atm. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
[Libevent-users] libev-1.4.0-beta release
As the subject says, a port of libev to libevent-1.4.0-beta is now available: http://dist.schmorp.de/libev/libev-1.4.0-beta.tar.gz Apart from all the goodies from libevent-1.4.0-beta, this also contains all the patches sent to me for integration in the libev parts, which include: - a small bugfix to kqueue (also present in the libev-1.3e release from yesterday) - the number of warnings have been reduced considerably, as a way was found to keep both msvc compatibility and not create warnings with gcc. - portability problems to solaris and some other OSs lacking standard C header files have been fixed. - documentation is now part of the release and will install itself as the ev(3) manpage, in addition to event(3). Thanks a lot for your contributions! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
[Libevent-users] [PATCH] relative timer with EV_PERSIST support + move event_del logic into event_active + regression tests
1. Make EV_PERSIST reschedule timeouts automatically.
2. New function: timeout_schedule: (nothing really new within it, just
modular wrapping of timeout rescheduling).
3. New macro: evutil_timercpy: tv_dst = tv_src in one line type deal;
3. Regression tests for persistent timeouts, include read/write, signals,
and timers.
4. Another regression test for signal handler restores (no problem, just
added another one).
So what this means is that if you do the following:
event_set(ev, fd, EV_READ | EV_PERSIST, read_cb, obj);
event_add(ev, timeout);
read_cb() will be called whenever a read event happens, and it's timeout
as passed to event_add() will be reset to the original value you passed.
You do not have to call event_add() within the handler.
event_set(ev, -1, EV_TIMEOUT | EV_PERSIST, timer_cb, obj);
event_add(ev, cycle);
timer_cb() will be called when timeout (as passed via cycle) expires. It
will then reschedule itself with it's original timeout, e.g. periodic timer.
You do not have to call event_add() within the handler.
For the event_del() changes, it's just moving event_del() into event_active(),
when an event occurs. There is a feature request on sourceforge for this,
and this couples nicely with the EV_PERSIST change. It also allows us to
rexamine the logic tests within the various event dispatchers themselves, as
event_active() will only delete the same event once.
-cl
$ test/regress
Testing Priorities 1: OK
Testing Priorities 2: OK
Testing Priorities 3: OK
Testing Evbuffer: OK
Testing evbuffer_find 1: OK
Testing evbuffer_find 2: OK
Testing evbuffer_find 3: OK
Bufferevent: OK
Free active base: OK
Testing HTTP Server Event Base: OK
Testing HTTP Header filtering: OK
Testing Basic HTTP Server: OK
Testing Request Connection Pipeline : OK
Testing Request Connection Pipeline (persistent): OK
Testing Connection Close Detection: OK
Testing HTTP POST Request: OK
Testing Bad HTTP Request: OK
Testing HTTP Server with high port: OK
Testing HTTP Dispatcher: OK
Testing Basic RPC Support: OK
Testing Good RPC Post: OK
Testing RPC Client: OK
Testing RPC (Queued) Client: OK
Testing RPC Client Timeout: OK
DNS server support: OK
Simple DNS resolve: type: 1, count: 1, ttl: 300: 152.160.49.201 OK
IPv6 DNS resolve: type: 3, count: 1, ttl: 922: 2610:a0:c779:b::d1ad:35b4 OK
Simple read: OK
Simple write: OK
Multiple read/write: OK
Persist read/write: OK
Combined read/write: OK
Simple timeout: OK
Persistent timeout: OK
Persistent read/write timeout: OK
Persistent signal timeout: OK
Simple signal: OK
Immediate signal: OK
Loop exit: OK
Multiple events for same fd: OK
Want read only once: OK
Testing Tagging:
encoded 0x0af0 with 2 bytes
encoded 0x1000 with 3 bytes
encoded 0x0001 with 1 bytes
encoded 0xdeadbeef with 5 bytes
encoded 0x with 1 bytes
encoded 0x00bef000 with 4 bytes
evtag_int_test: OK
evtag_fuzz: OK
OK
Testing RPC: (1.9 us/add) OK
Signal dealloc: OK
Signal pipeloss: OK
Signal switchbase: OK
Signal handler restore: OK
Signal handler spread restore: OK
Signal handler assert: OK
$ make verify
cd test make verify
make[1]: Entering directory `/home/clayne/project/libevent.build/test'
Running tests:
KQUEUE
Skipping test
DEVPOLL
Skipping test
POLL
test-eof: OKAY
test-weof: OKAY
test-time: OKAY
regress: type: 1, count: 1, ttl: 300: 152.160.49.201 type: 3, count: 1, ttl:
238: 2610:a0:c779:b::d1ad:35b4 (1.9 us/add) OKAY
SELECT
test-eof: OKAY
test-weof: OKAY
test-time: OKAY
regress: type: 1, count: 1, ttl: 300: 152.160.49.201 type: 3, count: 1, ttl:
1800: 2610:a0:c779:b::d1ad:35b4 (1.9 us/add) OKAY
EPOLL
test-eof: OKAY
test-weof: OKAY
test-time: OKAY
regress: type: 1, count: 1, ttl: 300: 152.160.49.201 type: 3, count: 1, ttl:
1800: 2610:a0:c779:b::d1ad:35b4 (1.8 us/add) OKAY
EVPORT
Skipping test
Index: event.c
===
--- event.c (revision 526)
+++ event.c (working copy)
@@ -125,4 +125,6 @@ static int timeout_next(struct event_bas
static voidtimeout_process(struct event_base *);
static voidtimeout_correct(struct event_base *, struct timeval *);
+static int timeout_schedule(struct event_base *, struct event *,
+struct timeval *);
static void
@@ -615,4 +617,5 @@ event_add(struct event *ev, struct timev
const struct eventop *evsel = base-evsel;
void *evbase = base-evbase;
+ min_heap_t *mh = base-timeheap;
event_debug((
@@ -627,12 +630,4 @@ event_add(struct event *ev, struct timev
if (tv != NULL) {
- struct timeval now;
-
- if (ev-ev_flags EVLIST_TIMEOUT)
- event_queue_remove(base, ev, EVLIST_TIMEOUT);
- else if (min_heap_reserve(base-timeheap,
- 1 + min_heap_size(base-timeheap)) == -1)
-
Re: [Libevent-users] [PATCH] relative timer with EV_PERSIST support + move event_del logic into event_active + regression tests
On Tue, Nov 13, 2007 at 06:15:00PM -0800, Christopher Layne wrote: 1. Make EV_PERSIST reschedule timeouts automatically. 2. New function: timeout_schedule: (nothing really new within it, just modular wrapping of timeout rescheduling). 3. New macro: evutil_timercpy: tv_dst = tv_src in one line type deal; 3. Regression tests for persistent timeouts, include read/write, signals, and timers. 4. Another regression test for signal handler restores (no problem, just added another one). So what this means is that if you do the following: event_set(ev, fd, EV_READ | EV_PERSIST, read_cb, obj); event_add(ev, timeout); read_cb() will be called whenever a read event happens, and it's timeout as passed to event_add() will be reset to the original value you passed. You do not have to call event_add() within the handler. event_set(ev, -1, EV_TIMEOUT | EV_PERSIST, timer_cb, obj); event_add(ev, cycle); timer_cb() will be called when timeout (as passed via cycle) expires. It will then reschedule itself with it's original timeout, e.g. periodic timer. You do not have to call event_add() within the handler. What was the original behavior? Did the timer disappear? If not, I fail to see how the new behavior is more justificed than the old; meaning, instead of changing it, why not add it as an option? If waiting to read an entire line, but you are trickled one byte at a time, do you really want to reset the timeout between bytes, or is the timeout meant to limit the time spent on reading the line? For the event_del() changes, it's just moving event_del() into event_active(), when an event occurs. There is a feature request on sourceforge for this, and this couples nicely with the EV_PERSIST change. It also allows us to rexamine the logic tests within the various event dispatchers themselves, as event_active() will only delete the same event once. Will this cause incompatabilities? What if you call event_add() anyhow? Will it return failure? This could silently break code. Maybe the user set EV_PERSIST, realized it didn't do what he wanted, but never removed it. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] relative timer with EV_PERSIST support + move event_del logic into event_active + regression tests
On Tue, Nov 13, 2007 at 06:27:58PM -0800, William Ahern wrote: event_set(ev, fd, EV_READ | EV_PERSIST, read_cb, obj); event_add(ev, timeout); read_cb() will be called whenever a read event happens, and it's timeout as passed to event_add() will be reset to the original value you passed. You do not have to call event_add() within the handler. event_set(ev, -1, EV_TIMEOUT | EV_PERSIST, timer_cb, obj); event_add(ev, cycle); timer_cb() will be called when timeout (as passed via cycle) expires. It will then reschedule itself with it's original timeout, e.g. periodic timer. You do not have to call event_add() within the handler. What was the original behavior? Did the timer disappear? If not, I fail to see how the new behavior is more justificed than the old; meaning, instead of changing it, why not add it as an option? If waiting to read an entire line, but you are trickled one byte at a time, do you really want to reset the timeout between bytes, or is the timeout meant to limit the time spent on reading the line? The original behaviour with EV_PERSIST was this: 1. Implicitly not delete our event, but do not reschedule the timer. 2. Merrily read/write/signal/etc. on an event and then out of the blue receive EV_TIMEOUT because the timeout was never rescheduled unless you explicitly did it (which one probably won't inutitively expect with EV_PERSIST). We went over this one before though. The issue is that the attacker crafting 1 byte data to keep connection open for eternity thing, while valid - I don't really see how it's a libevent issue. That's an application issue. Otherwise, with EV_PERSIST, the timeout added to the event no longer plays the role of a timeout once a single event happens on said event, and the timeout is not rescheduled manually. The concept of a timeout being tied to if we get a single unit of y bytes means the timeout is then a sideband module within said event now. However, receive 1 byte == event occured - and based on - that timeout should no longer be relevant to the situation that already occured. The example you bring up of wanting to read y units of bytes in a given time is still possible without EV_PERSIST, or by using an associated timer event (probably not preferred), etc. It's just that the previous example is so much an exception to the standard idiom of: wait_until_event_or_timeout(); do_stuff() || delete_myself(); reset_timeout(); With EV_PERSIST as it is, it's only convenient for exceptional cases rather than the norm - and that's the focus of this patch - to reverse that. -cl For the event_del() changes, it's just moving event_del() into event_active(), when an event occurs. There is a feature request on sourceforge for this, and this couples nicely with the EV_PERSIST change. It also allows us to rexamine the logic tests within the various event dispatchers themselves, as event_active() will only delete the same event once. Will this cause incompatabilities? What if you call event_add() anyhow? Will it return failure? This could silently break code. Maybe the user set EV_PERSIST, realized it didn't do what he wanted, but never removed it. event_add() will then reschedule the event based on the timeout you passed to it. But since it's already implicit with EV_PERSIST, it would just be a redudant but safe thing to do. -cl ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
