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...]
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
[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] [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] [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
[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
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
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] [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 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
