[Libevent-users] libevent-1.4.0 beta released
Hi everyone, I am pleased to announce the release of libevent-1.4.0-beta. This release contains major new features: - RPC subsystem that makes it easy to write distributed servers and clients - almost everything is documented via Doxygen now - many fixes and improvements to evdns and evhttp - libevent now builds two additional libraries: libevent_core (containing only the event core) and libevent_extras (contained evdns, evhttp and evrpc) - performance improvements due to using a heap instead of red-black trees for timeouts - Solaris' event ports are better supported Plus many other fixes - see the ChangeLog file for more details. You can download libevent from http://www.monkey.org/~provos/libevent/ I would like to thank Charles Kerr, Christopher Layne, Hannah Schroeter, Lubomir Marinov, Magne Mahre, Mark Heily, Maxim Yegorushkin, Nick Mathewson, Prakash Sangappa and Trond Norbye for their help. If you encounter any problems or would like to submit patches, let either Nick Mathewson or myself know or use the tracker at: https://sourceforge.net/tracker/?group_id=50884 Thanks, Niels. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] event.c: timeout_process(): let event_del() handle queue management
Thanks. Applied to patches-1.4 and trunk. Niels. On Nov 11, 2007 7:34 PM, Christopher Layne <[EMAIL PROTECTED]> wrote: > event_del() calls event_queue_remove(base, ev, EVLIST_TIMEOUT). > > -cl > > > ___ > 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] [OT] craigslist: libevent programmer wanted
On Sun, Nov 11, 2007 at 09:46:43PM -0800, Christopher Layne <[EMAIL PROTECTED]> wrote: > > Most unix systems cache data for quite long, butwhen they write, usually > > user mode apps also halt. For throughput this is of little concern, but > > in a game server I wrote, even an fsync could freeze the server for 15-20 > > seconds(!) when another sync was in progress at the same time, or when > > some othe rprogram geenrated lots of I/O (for example a backup/restore). > > BTW: This isn't a global Linux issue, it's specifically an issue with ext3 > and the > way it handles fsync() on a global scale. I am specifically not using ext3 anywhere on any of my systems, so, no, this has nothing whatsoever to do with ext3 and its many deficencies. > http://kerneltrap.org/node/14148 > > Personally, I use XFS (awesome design). Yeah, and even slower than ext3. By far. And this issue happens with xfs just the same. When memory grows tight and linux needs to flush, the system more or less freezes (w.r.t. I/O). I even see operations such as utime() freeze, even when everything is in the cache. (Ok, XFS is in fact the fastest filesystem when all you want to do is stream very large files, it can be very space-efficient, but at *anything* else it rather sucks, speed-wise). (And it fragments like hell, but at least it has an online defragmenter, which helps those very large files stream even faster). :) -- 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
Re: [Libevent-users] [OT] craigslist: libevent programmer wanted
On Mon, Nov 12, 2007 at 06:38:33AM +0100, Marc Lehmann wrote: > On Fri, Nov 09, 2007 at 12:39:37AM +0100, Hannah Schroeter <[EMAIL > PROTECTED]> wrote: > > I see less problems with the writing away of the data sucked from the > > web servers, as most Unix like systems write stuff asynchronously, so > > the open(..., O_CREAT...), write() and close() calls won't be too slow. > > Most unix systems cache data for quite long, butwhen they write, usually > user mode apps also halt. For throughput this is of little concern, but > in a game server I wrote, even an fsync could freeze the server for 15-20 > seconds(!) when another sync was in progress at the same time, or when > some othe rprogram geenrated lots of I/O (for example a backup/restore). BTW: This isn't a global Linux issue, it's specifically an issue with ext3 and the way it handles fsync() on a global scale. http://kerneltrap.org/node/14148 Personally, I use XFS (awesome design). -cl ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [OT] craigslist: libevent programmer wanted
On Fri, Nov 09, 2007 at 12:39:37AM +0100, Hannah Schroeter <[EMAIL PROTECTED]>
wrote:
> I see less problems with the writing away of the data sucked from the
> web servers, as most Unix like systems write stuff asynchronously, so
> the open(..., O_CREAT...), write() and close() calls won't be too slow.
Most unix systems cache data for quite long, butwhen they write, usually
user mode apps also halt. For throughput this is of little concern, but
in a game server I wrote, even an fsync could freeze the server for 15-20
seconds(!) when another sync was in progress at the same time, or when
some othe rprogram geenrated lots of I/O (for example a backup/restore).
(I hear the linux is abysmal w.r.t. writing out data (and I agree :),
but I found similar problems with freebsd, too, so I guess it is quite
common).
> And if they should be slower than the network interfaces, combine
> things with I/O worker {threads,processes}. BTDT (main program using
> event multiplexing on network + socketpairs to I/O helper processes).
If anybody uses perl, there is the IO::AIO module which provides this
quite efficiently (using only a single pipe to report results, and it is
only written/read once per poll, not per result).
--
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
Re: [Libevent-users] [PATCH] test/Makefile.am: out of srcdir fix
Thank you. Applied to trunk and branches. Niels. On Nov 11, 2007 7:27 PM, Christopher Layne <[EMAIL PROTECTED]> wrote: > > > ___ > 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
[Libevent-users] [PATCH] event.c: timeout_process(): let event_del() handle queue management
event_del() calls event_queue_remove(base, ev, EVLIST_TIMEOUT).
-cl
Index: event.c
===
--- event.c (revision 515)
+++ event.c (working copy)
@@ -815,7 +815,6 @@
while ((ev = min_heap_top(&base->timeheap))) {
if (evutil_timercmp(&ev->ev_timeout, &now, >))
break;
- event_queue_remove(base, ev, EVLIST_TIMEOUT);
/* delete this event from the I/O queues */
event_del(ev);
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
[Libevent-users] [PATCH] test/Makefile.am: out of srcdir fix
Index: test/Makefile.am === --- test/Makefile.am(revision 515) +++ test/Makefile.am(working copy) @@ -31,6 +31,6 @@ test: test-init test-eof test-weof test-time regress verify: test - @./test.sh + @$(srcdir)/test.sh bench test-init test-eof test-weof test-time: ../libevent.la ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] event.c: make internal signal event count as active
Thank you. I applied this to trunk.
Niels.
On Nov 10, 2007 9:14 PM, Christopher Layne <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 10, 2007 at 06:49:58PM -0800, Christopher Layne wrote:
> > On Sat, Nov 10, 2007 at 06:44:12PM -0800, Christopher Layne wrote:
> > > 11. here's the funny part: evsignal_process() increments
> > > event_count_active - but since our
>
> Here's a better patch:
>
> This removes docount entirely. docount is used to determine if the event being
> added or removed from the queue should influence base->event_count. The
> internal signal event should not be counted as an event to wait for
> - such that when one deletes all their events the event loop will
> not count the internal signal event as something to wait around for
> (nothing changes here). However, based on the previous discussion, it
> still needs to be processed as a normal active event, hence we change
> base->event_count_active regardless of if it's internal or not.
>
> -cl
>
> Index: event.c
> ===
> --- event.c (revision 507)
> +++ event.c (working copy)
> @@ -829,23 +829,17 @@
> void
> event_queue_remove(struct event_base *base, struct event *ev, int queue)
> {
> - int docount = 1;
> -
> if (!(ev->ev_flags & queue))
> event_errx(1, "%s: %p(fd %d) not on queue %x", __func__,
>ev, ev->ev_fd, queue);
>
> - if (ev->ev_flags & EVLIST_INTERNAL)
> - docount = 0;
> -
> - if (docount)
> + if (~ev->ev_flags & EVLIST_INTERNAL)
> base->event_count--;
>
> ev->ev_flags &= ~queue;
> switch (queue) {
> case EVLIST_ACTIVE:
> - if (docount)
> - base->event_count_active--;
> + base->event_count_active--;
> TAILQ_REMOVE(base->activequeues[ev->ev_pri],
> ev, ev_active_next);
> break;
> @@ -866,8 +860,6 @@
> void
> event_queue_insert(struct event_base *base, struct event *ev, int queue)
> {
> - int docount = 1;
> -
> if (ev->ev_flags & queue) {
> /* Double insertion is possible for active events */
> if (queue & EVLIST_ACTIVE)
> @@ -877,17 +869,13 @@
>ev, ev->ev_fd, queue);
> }
>
> - if (ev->ev_flags & EVLIST_INTERNAL)
> - docount = 0;
> -
> - if (docount)
> + if (~ev->ev_flags & EVLIST_INTERNAL)
> base->event_count++;
>
> ev->ev_flags |= queue;
> switch (queue) {
> case EVLIST_ACTIVE:
> - if (docount)
> - base->event_count_active++;
> + base->event_count_active++;
> TAILQ_INSERT_TAIL(base->activequeues[ev->ev_pri],
> ev,ev_active_next);
> break;
>
> ___
>
> 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
[Libevent-users] libev-1.3e beta release
Hi! 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 It has now been tested on freebsd, linux, windows and os x, and is used by a number of gvpe and urxvt installations by now. Here are the highlights/changes: - an enourmous number of bugs have been fixed. I really wonder how it ever worked before (yeah, obviously, because the basic stuff worked :). - the select backend has been completely rewritten and now supports FD_SET and direct-access modes (as well as win32). - the select backend can optionally be told to use the raw winsocket select, and libev will cache osf handles in this case (fd-based selects are still supported). - poll has been bugfixed. - the code has been compiletested as c++. - kqueue has been considerably improved. - the libevent emulation now declares and manages the ev_flags member (in a half-assed way, more work would be neeccessary to really support this member perfectly). - whoever had issues with the word shit in the source, I found a simpler, less annoying way to work around some bugs in msvc, and consequently could avoid using shit (not sure wether the new version is any better, though :) - both poll and kqueue have been found to be defective on os x, and the libevent test for broken kqueue does not detect this condition, so for the time being those backends are disabled. - there is the beginning of a c++ adaptor which is designed to replace the older io_manager event loop to some extent. - a number of embedding features such as being able to override more behaviour, better autoconfiguration or beginning autoconf-support (example usage is in both urxvt and gvpe). Thanks again for all your feedback, but especially to Emanuele Giaquinta, who constantly helped me check the design for flaws and tested, and tested, and tested... If this continues for a few months, I think libev will be quite capable of replacing libevent completely. -- 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
Re: [Libevent-users] C++ interface(s) [was: libev-1.3e...]
On Sun, Nov 11, 2007 at 08:04:10PM +0100, Chris Brody <[EMAIL PROTECTED]> wrote: > My first comment is that building with EV_MULTIPLICITY=1 (the default > value) caused a few problems since there is both a struct ev_loop and Thanks a lot (I really never tested with EV_MULTIPLICITY, so I am pleasently surprised you even got some results... :) > an ev_loop() function call. In addition, the EV_P (and EV_P_) macros > require the user code to use "using namespace ev"... user code should not need to use those macros... when does the need come up? (in fact, there should not be any macros defined, but I guess thats not reasonable, so maybe in the long run ev will have to end up in the std namespace) > does exhibit a few quirks. For any C++ class that is called by > interpreted code, CINT has to parse the header file and make a dynamic > library that is called in reaction to interpreted C/C++ code. It is > only "85%" compliant and has real trouble with significantly templated > code. Ok, I wonder wether ev++ counts as heavily templated or not :) > But if I make a C++ subclass (or several C++ subclasses) that are less > complex, these should be more straightforward to be used dynamically. > I will try this and provide some more feedback. Thanks! -- 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
Re: [Libevent-users] libev-1.3e demo release - kqueue ident/fd issue?
On Sun, Nov 11, 2007 at 04:42:41PM +0100, Chris Brody <[EMAIL PROTECTED]> wrote: > I suspect there is a very strange error event if there is a small > delay between write()/shutdown() and event_add()/event_dispatch(). Ok, if the patch indeed is correct, then it isn't (because it doesn't range-check the fd, which is the real problem). But the real issue is why kqueue returns errors to us for requests we never made, this feels like quite the bug in kqueue (I hope you don't use mac osx, I just found out that both poll and kqueue are broken and the libevent test doesn'T detetc this brokenness on macosx). > I tried adding a check of the fd, and this seems to work well. I must > admit that I am no kqueue expert, but I hope this information is > helpful. Possible patch below. Could you make it crash again and send me the contents of "res" and kqueue[i]? Its quite possible that I don't use qkueue right, or something else goes bad. In which case ignoring the error would never give us the chance to find out. Thanks a lot! -- 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
Re: [Libevent-users] C++ interface(s) [was: libev-1.3e...]
Hi Marc,
I went through the libev++.h and managed to re-hack the
functor-way.cpp signal test for libev++.
My first comment is that building with EV_MULTIPLICITY=1 (the default
value) caused a few problems since there is both a struct ev_loop and
an ev_loop() function call. In addition, the EV_P (and EV_P_) macros
require the user code to use "using namespace ev"...
I am using the CINT C++ interpreter for my personal project, which
does exhibit a few quirks. For any C++ class that is called by
interpreted code, CINT has to parse the header file and make a dynamic
library that is called in reaction to interpreted C/C++ code. It is
only "85%" compliant and has real trouble with significantly templated
code.
But if I make a C++ subclass (or several C++ subclasses) that are less
complex, these should be more straightforward to be used dynamically.
I will try this and provide some more feedback.
Thanks,
Chris
On Nov 11, 2007 4:32 AM, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> [note that i replied to the list, I hope this was ok, as I think a c++
> interface *might* interest other users too. If anybody finds it too
> off-topic, tell me and I will repent :]
>
> On Fri, Nov 09, 2007 at 07:32:13PM +0100, Chris Brody <[EMAIL PROTECTED]>
> wrote:
> > > start ()
> > > stop ()
> > >
> > > and would complement libev nicely as its quite object-oriented in design.
> > Yes-I definitely like this idea, with such an immediate re-use for a
> > wide-spread application.
>
> I tried it, but found it was quite the nuisance and made the header file
> rather ugly.
>
> Since I am in immediate porting needs to replace my older iom.C solution in
> gvpe and urxvt, I started a c++ interface.
>
> It is very similar to iom.C (and also very similar to libev, of course),
> but provides a bit more fluffyness (you can call ->set anytime and it will
> automatically stop/restart the event watcher).
>
> Its currently only useful for embedding (its in the files ev++.h and
> ev++.C), but I didn't chose to override the callback proper, so one can mix C
> users of libev and c++ users of the same.
>
> > I am thinking about how to make some kind of "thunk" callback
> > connector to go directly between libev and eventxx.
>
> This is what ev++.h also does, to keep full ABI compatibility. ev++.h is
> currently more or less providing simple wrappers around the watchers allowing
> object methods as callbacks.
>
> What is missing would be a nicer namespace cleanup (wrapper functions so
> ev_xxx becomes ev::xxx not ev::ev_) and a nice event loop and default
> loop abstraction.
>
> (I will probbaly switch to using enums for constants in ev.h at one point,
> although this is not quite as helpful as one would assume :)
>
> > If you do make this one, I will also consider how to use it with eventxx.
>
> Not having analyzed eventxx in detail, I believe the interfaces to be
> quite different in style, with ev++ being quite a bit more primitive
> (except in its callback system which is more complex).
>
> Here is an example use (more or less straight from rxvt-unicode):
>
>struct term {
> void cursor_blink_cb (ev::timer &w, int revents); ev::timer
> cursor_blink_ev;
> ...
>};
>
>term::term ()
>: cursor_blink_ev (this, &term::cursor_blink_cb)
>{
> ...
>
> if (option (Opt_cursorBlink))
>cursor_blink_ev.start (CURSOR_BLINK_INTERVAL, CURSOR_BLINK_INTERVAL);
>}
>
>void
>rxvt_term::cursor_blink_cb (ev::timer &w, int revents)
>{
> hidden_cursor = !hidden_cursor;
> want_refresh = 1;
>}
>
> As you can see, there are aliases for start that also set the time - I did
> this because I had lots of code using the convention, and it doesn't seem to
> hurt the interface.
>
> For multiple event loops (not really tested), the constructor has an
> additional argument for the event loop to associate with (using the
> default event loop if not given), and also has a set method that changes
> association.
>
> This is neccessary because I decided that the destructor has to call
> stop(), which requires storing the event loop inside the watcher
> somewhere.
>
> Anyways, this is just a start to convert my existing projects, but it
> seems to work quite well.
>
>
> --
> 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
Re: [Libevent-users] libev-1.3e demo release - kqueue ident/fd issue?
Thanks for the fixes so far. I am still using the "embedded" version
in my C++ interpreter project and found a strange issue with the
kqueue_events[i].ident. In a heavily-adapted version of the
test-eof.cpp test program, if I run it with CINT using ev_kqueue.c
from CVS, I get a crash on line 121 with fd=a very large number.
However, if I do not use eventxx::dispatcher, the same test works OK.
I suspect there is a very strange error event if there is a small
delay between write()/shutdown() and event_add()/event_dispatch().
I tried adding a check of the fd, and this seems to work well. I must
admit that I am no kqueue expert, but I hope this information is
helpful. Possible patch below.
Thanks,
Chris
$ diff -u ev_kqueue.c ev_kqueue4.c
--- ev_kqueue.c 2007-11-11 16:41:43.0 +0100
+++ ev_kqueue4.c2007-11-11 16:19:19.0 +0100
@@ -118,7 +118,7 @@
*/
/* we are only interested in errors for fds that we are
interested in :) */
- if (anfds [fd].events)
+ if (fd_valid (fd) && anfds [fd].events)
{
if (err == ENOENT) /* resubmit changes on ENOENT */
kqueue_modify (EV_A_ fd, 0, anfds [fd].events);
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
