embed kqueue/epoll heads-up
I did some further testiong of libev's ability to embed event loops, and I found they do not work anywhere. Unfortunately, the breakage is in the kernels, with no apperent workaround possible. My findings are: - an epoll fd always returns as readable wether events are ready or not. - on netbsd and freebsd, polling on a kqueue fd has no effect, it will not become readable even when events are pending. that means on freebsd, the *highest-performing generic event mechanism* is poll or select. what a shame. (the breakage on netbsd and linux is unfortunate, but rules out only i/o prioritising, while still leavign epoll and kqueue as generic event mechanisms). I will update the documentation accordingly (with the next version fo the perl interface, multiple event loops will also be supported in perl, so one can now choose kqueue there as well even on systems where it only works for sockets). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Warnings from gcc
On Fri, Dec 21, 2007 at 05:18:56PM -0500, Jeff Squyres [EMAIL PROTECTED] wrote: libev that was configured with ./configure CFLAGS='-Wall - pedantic' (or even just -Wall). I didn't compare closely, but I see Read the documentation on -pedantic. I know you don't like reading documentation, but it is sure worth it. Also, compiling with -pedantic is not supported, as we will freely use gcc extensions when gcc is available (even if it might compile), which is not possible with -pedantic (pedantic is *not* a sensible warning option, but best read the gcc docs). Before analyzing these any further, do you care? No. Warnings are warnings, and every compiler has different ones and different tastes. If you know how to silence those warnings a) without introducing slowdowns and b) on every compiler, then I would like to hear about them. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Warnings from gcc
On Sat, Dec 22, 2007 at 06:18:12PM -0500, Jeff Squyres [EMAIL PROTECTED]
wrote:
static struct ev_loop *
ev_default_loop (unsigned int flags) { ... }
Should that function be marked as inline?
No, because inline semantics are not portable at the moment (C99 vs.
gcc),
so static is the closest equivalent.
Also FWIW: AC_C_INLINE can take of this for you -- here's its
description:
Jeff, please read what I wrote. You do not understand what inline means
and how C compilers generally work. I do not see how AC_C_INLINE is
relevant, as it doesn't tell me about inline _semantics_ and how to use
it, and it requires autoconf. Also, the current code and semantics are
*correct* and the wanted ones, and not using the inline function might
generate a warning as well, so silencing it in gcc is of little value.
If you are concerned, do not use -Wall in production builds (using -Wall
is basically a mistake in production builds as it includes an unknown,
often changing and sometimes broken set of warnings that will only scare
users). Please do not think that a warning indicates any problem with the
code whatsoever.
Because of our communications history, wouldn't it be possible to
send an actual developer who knows C and portability a bit? It is a
bit tiresome to have to explain C keywords and unix functions to you,
especially as portability issues require some experience, and my patience
admittedly has worn out a bit.
(Questions are ok, but if you do not like my answer because it doesn't
make sense to you you should first clarify it).
libev has been checked for relevant compiler warnings (on the
platforms
and with the compilers I use only of course).
Fair enough. Is OS X one of those platforms? (I couldn't find an
official list of supported platforms -- did I miss it?)
OS X is not one of those, but since afaics only gcc is used the warnings
should be comparable to similar platforms.
The list of official platforms is:
- POSIX (all)
- Winsockets (Windows 2000+, maybe earlier)
- Perls select emulation on windows
Currently this apparently rules out OS X (which is utterly, dearly,
almost unusably broken), but libev does survive its testsuites there
(with select, the only working backend on OS X), so while not officially
supported (due to lakc of resources) it should generally work there.
A related (but probably random) question: are there any correctness
tests for libev?
I use both the libevent regression tests and also have a number of tests
on my own (the latter are all part of the perl module).
own stuff every night in an automated test harness; I'd be happy to
add libev (standalone; outside of the other stuff I test) to the mix
with a variety of platforms and compilers if it would be helpful.
Just run make test in the perl module, and if more is desired, use the
regression test in the libevent+libev tarball.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=/_/_//_/\_,_/ /_/\_\
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: ev_stat missed?
On Thu, Dec 20, 2007 at 05:36:38PM +1000, Anton Umnikov [EMAIL PROTECTED] wrote: I got error test_ev_stat.c:39: undefined reference to `ev_path_set' when I tried to compile simple test with using of ev_stat. Is ev_stat not availabe yet? No, thats simply a typo, stat watchers were called path watchers before. Use CVS, or separate initialisation like this: ev_init (w, cb); ev_stat_set (e, path, interval); /* /etc/passwd changed in some way */ also, the example doesn't show this (yet), but one should generally act on stat changes one second after it was signalled, as stat() only has a resolution of one second and one might otherwise skip updates (the exception is when time is irrelevant and size suffices as change indicator for example). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Announcing Rev: a high performance event library for Ruby 1.9
On Sat, Dec 29, 2007 at 01:21:43AM +, Thomas Hurst [EMAIL PROTECTED]
wrote:
Also, :backend = :kqueue makes it crash horribly there ;)
libev doesn't require too much error handling, except when initialising an
event loop. the perl interface does something like this:
default_loop
or die 'EV: cannot initialise libev backend. bad $ENV{LIBEV_FLAGS}?';
The message for Rev could be similar (and obviously include the :backend
= xxx case).
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=/_/_//_/\_,_/ /_/\_\
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Why does libev comes with event.c and event.h?
On Tue, Jan 08, 2008 at 12:03:18PM -0200, Leandro Lucarella [EMAIL PROTECTED]
wrote:
Hi! I'm making a debian package out of libev-2.01.tar.gz and I founded
that it comes with event.{c,h}. I thought libevent compatibility stuff
only came with libevent-1.4.0-beta+libev-2.01.tar.gz.
No, the libevent core API compatibility layer is an integral part of libev.
The problem is the resulting package conflicts with libevent package
(because both have event.h),
I guess thats correct, because both offer this API and such are alternatives
for the libevent core API.
but it has not much sense because no libevent.{a,so} are built anyways
(or is event.c compiled into libev.{a,so}?).
event.c is compiled into libev indeed.
I can make a workarround removing event.h from the package, but I was
under the impression that libev distrubution was free of libevent stuff.
To the best of my knowledge, libev is free of libevent stuff, meaning
code and header files, but the libevent compatibility layer is of course
not taken from libevent (it doesn't need a compatibility emulation for
itself), but part of libev (see the copyright statements in event.h and
event.c).
Is this a bug or I was under a wrong impression? =)
I would say its a feature. Removing event.h would break it.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=/_/_//_/\_,_/ /_/\_\
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: kqueue for sockets on freebsd (non-polling)
On Wed, Jan 09, 2008 at 01:20:35AM -0800, Eric Brown [EMAIL PROTECTED] wrote: Anyway, I read a number of concerns about libev kqueue. What concerns? libev supports kqueue just fine... It is kqueue that is making problems on most BSDs, though. Since all I care about are sockets, can I get libev to use kqueue in an efficient non-polling mode? Or am I better off looking at libevent or using kqueue directly? What do you mean with kqueue in non-polling mode? afaik, kqueue only supports a polling mode, and this is what both libevent and libev use. Sorry, I'm new to libev and kqueue - more used to using select() directly or other higher level APIs. But libev looks really great. Thanks. While, of course, I think that libev has a lot of advantages over libevent (such as a more rational API (espeically when multithreading) and higher performance), libevent is certainly adequate to the job as well. You should probably look at the libevent example program, and the libev documentation (which also has examples) and choose the one that appeals most to you. If you are only interested in sockets and simple timeouts, then both libraries have the same feature set (although understanding how timeouts work in libevent can be difficult, it certainly was for me). libevent example: http://monkey.org/~provos/libevent/event-test.c libevent docs: http://monkey.org/~provos/libevent/doxygen/ libev docs: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod If you insist on using kqueue everywhere (watch out, its buggy on most os x releases even for sockets), then this will give you an event loop using kqueue in libev, whenever kqueue is available: #include ev.h struct ev_loop *loop = ev_loop_new ( ev_recommended_backends () | EVBACKEND_KQUEUE ); assert ((loop, libev initialisation failed)); -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: kqueue for sockets on freebsd (non-polling)
On Wed, Jan 09, 2008 at 10:20:13AM -0800, Eric Brown [EMAIL PROTECTED] wrote: wasn't always clear to me as to whether the concerns were about kqueue or about the way libev uses kqueue. Hence my question. :) Assuming I go with libev (likely), I'm developing on leopard but my target is freebsd. If there's some amount of testing you need, let me know. Not really, by now, I know mostly what to expect. It was just my initial suprirse to see how broken kqueue really is, in practise, because nobody has seemed to try to use it as a replacement for poll/select in normal programs. What do you mean with kqueue in non-polling mode? afaik, kqueue only supports a polling mode, and this is what both libevent and libev use. I'm talking about kevent(..., const struct timespec *timeout). Since I don't care about signals, fork events, etc. - all I care about is sockets - I don't think I want a 0 timeout in the call to kevent(). I see ev_set_io_collect_interval and I'm guessing this is what controls that? So by polling, all I meant was use of kevent with a 0 timeout. I don't see why you want to rule out kevent with a zero timeout. The way to avoid a zero timeout is to call ev_set_timeout_collect_interval (_not_ io), because the timeout parameter is tied to the timer handling (when put this way its obvious :) I am, however, curious as why you'd want to avoid kevent calls with a zero timeout? Under normal operations, libev will not call libevent with a zero timeout, but if it does, its usually for good reasons (and then you cannot avoid it), and without understanding exactly what problem to solve, I would suggest against setting any of the collect intervals - they are very specific, advanced functions not normally necessary to achieve specific performance (they can improve efficiency, e.g. at powresaving, at the expense of latency, which should be a rare thing tor equire for a busy server). But then, if you need it, its there. Just think twice before using it without knowing exactly why you need it. Thanks! I'm being told by a customer to use kqueue. At least with libev I can easily switch to something else if it doesn't work out. Even without recompiling (and to some extent, also with libevent :). BTW, I'm told I need to support 1000s of connections. But my suspicion is that reality may be in the low 100s. On a fast server, do you have any idea where the cross-over is between poll/select and kqueue Thats hard to say: select and poll on bsds are implemented differently, and usually are slower no matter what, so the break even point would be at or near 0 connections :) It all depends on how you use it, of course: if most of your connections are active, then select can be quite adequate, if most of your connections are idle (the more common case) then select will likely be rather bad even at a few dozen connections. And again, if you app spends seconds processing each conenction, then the slowdown caused by select will not be noticable, either. In general, I would *expect* kqueue to compare fabvourably in all cases against select, and certainly with a few hundred connections. performance? I see your benchmarks, but I don't think they compare different mechanisms. The libevent homepage has two graphs comparing different mechanisms. They are pretty adequate to show the basic different between select and another mechanism, but the break-even point depends on many external factors. In any case, if you want a second opinion on a problem, feel free to present your problem here (its usually easier than verifying a solution to an unknown problem), thats what the mailinglist is for, so don't hold back. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Bug with signal delivery after fork.
On Mon, Jan 14, 2008 at 10:56:54AM -0500, Chris Shoemaker [EMAIL PROTECTED] wrote: Hi, I believe the attached program demonstrates some bug related to signal delivery after a fork. Thanks for the test program, I will have a look asap. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [PATCH] Only compile ev::now() if EV_MULTIPLICITY is defined.
On Tue, Jan 15, 2008 at 10:06:32AM -0200, Leandro Lucarella [EMAIL PROTECTED] wrote: Marc Lehmann, el 15 de enero a las 04:13 me escribiste: On Mon, Jan 14, 2008 at 01:35:22PM -0200, Leandro Lucarella [EMAIL PROTECTED] wrote: Since ev_now() not available if EV_MULTIPLICITY is not defined, it has not much sense having a ev::now() that calls an inexistent ev_now() ;) not sure what you mean, ev_now is available regardless of any value for EV_MULTIPLICITY? I mean, in ev.h says: # if EV_MULTIPLICITY /* ... */ ev_tstamp ev_now (EV_P); /* time w.r.t. timers and the eventloop, updated after each poll */ Look at the #else part, ev_now is available nevertheless (my apps use it, I am quite sure it is there :) But in ev++.h there was no conditional compilation for ev::now(), that uses ev_now(). And quite correctly so, as ev_now () is supported regardless of EV_MULTIPLICITY :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Disabling the SIGCHLD handler
On Tue, Jan 15, 2008 at 10:47:33AM -0500, Chris Shoemaker [EMAIL PROTECTED] wrote: It's O(N) in the number of child watchers, and runs only upon SIGCHLD. Also, it just occured to me that this is totally misleading: Your algorithm is O(c²) where c is the number of children in the number of waitpid calls, where libev is O(c). If you take into account the number of watchers, then your approach is O(w c²) where w is the number of watchers, while libev's approach is O(w c) with a much smaller constant factor due to the hashing. As an example, with just 50 children, in the worst case, you require over 1200 waitpid calls where libev only requires 100, and each waitpid call, if implemented correctly, would have to check all active watchers in your case (leading to over 3 iterations overall), and only the potentially matching ones with libev (leading to roughly 150 iterations overall). Performance quickly degrades from that point on. It makes sense to implement it that way for you because you are required to emulate a non-event-based API (waitpid) and there is little to do, but punishing programs written in an event-based way makes no sense to me, especially in an event-library: It is only natural that non-event-based approaches might require less efficient algorithms. Sure, 50 children is not typical, but it happens with some regularity, just as 1000 or more file descriptors is not typical, but it happens with some regularity. Is that really so bad? I'd love to know of a more efficient way, but efficiency is secondard to correctness, libev *is* correct, it just isn't suitable for emulating waitpid, as it is a generic event library. When talking about correctness, I'd say the correct approach is to deliver data to the registered watchers, and not just some of them. (thinking about all this, I might be able to reduce the number of waitpid calls further). In any case, libev is commited to support event-based programing efficiently, it is not meant to emulate the traditional UNIX api in a different way: if you want waitpid, you know where to find it. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Disabling the SIGCHLD handler
On Tue, Jan 15, 2008 at 08:28:34PM -0700, Tony Arcieri [EMAIL PROTECTED] wrote: Marc, could you check out the Rubinius code? I know when you looked at Rev you spotted some obvious problems right away. If there's a problem with the way Rubinius is doing SIGCHLD maybe you could correct it and move it on to ev_child. Or, perhaps you'll discover some irreconcilable or otherwise difficult problem. I do not think I have the time for that: this has nothing to do with libev, so my personal interest is low, and I am very low on time in general. Sorry. (I only looked at Rev to see how one would do that in ruby, out of interest, and because seeing bugs might hint at what could be improved, for example, in the documentation). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [RFC] extending ev++.h to add C++ loop wrappers.
address =P). I can go back to the loop_ref approach, but it has its own issues, which I forgot now :S Why would one want to go back to the loop_xxx object? I don't see any reason to do so, as it has no state whatsoever (as all state is stored in struct ev_loop, and either the interface is lean and simple and has no state, or it adds something over the ev loops, which wouldn't make it simple anymore). And I really think it's much more simple and elegant the new approach, I wouldn't say its inherently more or less elegant, its different... I am not sure wether it would be simpler: the non-virtual approahc would create simpler objects, probably less management code and would overall be faster. even when it forces you to use the loop wrapper (which you can pass to C API functions too, so that shouldn't be a huge problem either). If I cna pas it to C API functions, why not also allow it to be passed to the watcher? Whats the inherent advantage of having the same address for the same loop pointer (consider the loop objects meerely pointers once)? What counts is the identify of the underlying loop. i.e. your approach could be beiwed like this: struct ev_loop *myloop = ... and then pass around myloop as *the* loop because you think it is important that the address of all loops point to myloop, but in fact, the only important thing is that the underlying loop is the same one (i.e. the contents, not the address). I agree that your approach is nice and c++'ish, but wasn't one of the goals of ev++.h to be lean and simple and to be very close to the ev.h API? Right now, I can mix and match the C++ with C API in my programs whenever its convinient, eith ev++.h I have a insular kingdom where only ev++'s loop work (for example, the problem comes up when C++ code needs to use the loop created by some C code, consider a program written in C++ that needs to access a library that creates its own event loop. ev++.h currently has no nice simple and elegant way to make that possible). Even more, if the default_loop_ptr is exposed, all virtuality could be avoided, so no overhead at all will be introduced in the loop wrapper Yes, either that, or we allow ev_loop_destroy and ev_loop_fork for the default loop as well: Since ev++.h is part of libev, we could even call this a hidden implementation detail. In fact, one could even export a ev_loop_is_default() predicate in ev.h for that and other purposes, without exposing the internal pointer to ev++.h (or, heaven forbid, even other parts :) One would lose the ability to compare loop_base's by address, but a nice operator == would do that or somesuch, if needed. There are several problems with this. First, ev_loop struct is not available in ev.h =) How is that a problem? You can still pass around pointers to it, and that is all that is required. Second, I wrapped the loop not only for cosmetical purposes, I like the automatic destruction =). If you lost the difference between an object and a raw pointer, then you can't know when to call the ev_xxx_destroy() (unless we use reference counting, which I think is overkill for this case). You can have automatic destruction by providing three types: ev::loop // for storing loops ev::loop_dynamic // for dynamically-created loops ev::loop_default // for the default loop Naming could probbaly be improved, but you need these three types anyways, to be able to handle externally-provided loop pointers (which certainly will come up). -void start (int fd, int events) +void start (int fd, int events = READ) Do you really think this is such a good idea? Is READ really predominantly what people want? Is what I predominantly want =) Well, if you think so, ok then. I can remove the default... Not if you are convinced its what people predominantly want. I have as much data on that as you (i.e. mostly my own: I have more READ than write watchers, but I don't see why it should be the default. Think readability: start (fd); // waits for read events this doesn't look intuitive when I remove the comment). But feel fre to overrule me here again. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [RFC] extending ev++.h to add C++ loop wrappers.
On Wed, Jan 16, 2008 at 03:37:12PM -0200, Leandro Lucarella [EMAIL PROTECTED] wrote: Well, I think its a wonderful idea, its a loop, it should be called loop :) If we call it loop, then the loop() method has to be called other way, that's why I didn't call it loop. Maybe loop - start, unloop - stop (like watchers? but since they are radically different methods, maybe the must be called otherwise). Maybe just loop - do_loop? loop::run () // flags=0 loop::one_iteration () // once loop::sweep () // nonblock would be possible :) Or even: loop (); :- the reason it is called ev_loop is caused by a limitation in C's object orientation, and I think we can get away with renaming it here (it actually is taken mostly from libevent, and today I think maybe its not that good an interface). I am not saying we should rename it, its basically the question wether we want to use something ugly like loop_ref and a loop_ref::loop, or a loop, and a renamed (nut nice) loop::run (). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Another race in signal handling
On Mon, Jan 21, 2008 at 11:25:49AM -0500, Chris Shoemaker [EMAIL PROTECTED] wrote: I figured that describing the exact time when interuption by a signal causes signal watchers to be indefinitely delayed would be helpful, Again, it would have been helpful when you had done that, but instead you came up with an obviously wrong (because it doesn't match the code) explanation that is not helpful to anybody. A good explanation is actually better than a testcase, but a wrong one is simply absolutely useless, while a testcase is a tedious but sure way to find bugs. but if you find testcases more helpful, I'm very glad to oblige. In this case, it is the only thing you delivered, so there is no more helpful here - the choice is between an explanation that has nothign to do with the code or the problem, or a testcase. Given that choice, it is obvious that a testcase is more helpful. Here it is I cannot reproduce that with the current (CVS) version and various settings for the interval timer, but it looks like a race condition that was recently fixed in libev regarding forking and signal delivery (where signal delivery could indeed be delayed). Your fix of removing gotsig only has the effect of shrinking the time window of this problem occuring, it doesn't fix any underlying issue at all. You really shouldn't hack around in the code without understanding it. It really is best to let people fix it who understand it, lest you will run blindly into problems that are much harder to debug (because much rarer). It is, however, your right to hack around in libev, and if you feel you must add bugs to it, or obfuscate existing bugs without fixing them, you should do it. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: New iteration over the ev++ improvement patch.
On Mon, Jan 21, 2008 at 11:25:52PM -0200, Leandro Lucarella [EMAIL PROTECTED] wrote: Well, the compiler complained about changing the meaning of loop in the context of the watcher's base class, but adding the namespace to the type when declaring the loop variable did the trick. I'll commit this patch unless you have something against it: http://git.llucax.com.ar/?p=software/libev.git;a=commitdiff;h=a4f6c6a06077bcd9e208c064ebed9e577f8c (I added operator () as an alias to run ()). Looks fine, but please do not use EV_THROW for the exception specification (I changed thta in CVS already), but instead use plain throw (). The main drawback of using exceptions is using stdexcept, not specifying what a function throws. I don't find anything natural at all at calling as do-called init method in C++, shouldn't this be done by the constructor? :) Yes, but you didn't like the explicit default_loop instantiation =) And the loop has to be initialized somewhere... Yes, when first accessed, e.g. here: ev::io myw(ev::default_loop); would be fine. My proposal does just that without static initialisation. In any case, I leave the final decision on how to implement this up to you :) For the sake of simplicity I think I'll go with the global function returning a loop_ref. It's the closest to C API so if someone don't like it I can blame you =P Given that I proposed a global variable without automatic intiialisation, I will promptly point back at you :) Seriously, I see 2 main use cases: 1) Use the default_loop just once, like the unloop() call in a callback. 2) Use the default_loop more often. In case 1), the extra () is not such a big deal. In case 2), you'll probably store the loop in a local variable for convenience (and/or performance), so no problem there. If that's ok with you, I'll apply this patch to CVS too: http://git.llucax.com.ar/?p=software/libev.git;a=commitdiff;h=cb6fa5ebc2f52e7224708fecf85032342d8ebeb8 I am ok with that in any case, I sodner you the principal architect of the c++ interface :) In any case, I don't see anythign wrong with providing mere function wrappers for the ev namespace, as the goal should be to take the C api and c++-ise it a bit, so if there is no obvious problem with using the c api approach, sounds perfetc to me :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: New iteration over the ev++ improvement patch.
On Mon, Jan 21, 2008 at 10:26:54PM -0200, Leandro Lucarella [EMAIL PROTECTED] wrote: Because we cannot initialise that static variable, or the user again ahs to call a method, which brings us back to the beginning of havign a method that needs to be called. User will need to call a method/funtion always, Not with the solution I proposed, no? calling the constructor is less explicit, but you didn't like the explicit instantiation either. So I don't understand what's your idea. Giving the user a variable instead of having to call a method. Remember the reason for this static thingabob was to avoid having to call a method in the first place. I don't remember. I don't understand what you mean either :) Well, read back the e-mail thread then :) The starting point was that we would like to have a cariable instead of havign to call a function (a syntactical thing), and I provided a way to do that. The redeeming quality of that is that we could replace it by a variable at a later time. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: New iteration over the ev++ improvement patch.
On Tue, Jan 22, 2008 at 03:31:12PM -0200, Leandro Lucarella [EMAIL PROTECTED] wrote: The main drawback of using exceptions is using stdexcept, not specifying what a function throws. Well, I think you did a little more than what I expected. You made throwing bad_loop non-conditional. I think it make no sense to keep the conditional compilation just to set if std::runtime_error is used or not. Well, its the difference between rxvt-unicode compiling or not (it doesn't use the standard library), which I consider extremely crucial :) The main point of the conditional compilation were to avoid the overhead of exceptions, not the overhead of an (standard) include. What overhead of exceptions? Not calling throw doesn't, in general, avoid any overheads compilers add (and removing the throw specifications will, at best, introduce overheads because the compiler now has to deduce that no exceptions will be thrown (which is impossible in this case)). The runtime overhead is virtually nonexistant because you never really throw it except in, well, very exceptional conditions. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [Libevent-users] pipeline server
On Mon, Feb 25, 2008 at 02:32:00PM +0100, Chris Brody [EMAIL PROTECTED] wrote: I would like to suggest that you take a look at libev (http://software.schmorp.de/pkg/libev.html), which has a libevent compatibility API but also has a number of watchers to deal with multiple threads. I do not understand these at all, but maybe they would make more sense to you. Well, I just hope you didn't read the ev_async documentation, as otherwise, it clearly fails to explain what they do :) In any case, its quite simple: all you can do with them is generate an event in another event loop that might currently be active in another thread, which is the basic building block one needs for inter-thread-communications. You would also need current cvs, as this has not yet been released, and be aware that some users experienced unspecified (and so far unreproducable) problems with slightly older cvs snapshots, so ymmv. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: small pb
On Sun, Mar 02, 2008 at 04:27:31PM +0100, [EMAIL PROTECTED] wrote: The small fix below allows libev to compile with large file support if the system supports it. The problem is that it breaks the ABI for all other programs. I do not think there is a solution for that short of recompiling the way one wants it (otherwise this forces extra compilation flags that are non-default on every libev user). Thanks for bringing this to my attention, however, I will likely document the issue or maybe even enforce lfs support in the standard package. Or maybe I will bite the bullet and do my own struct stat with onlys the documented members. That would simplify introduction of subsecond file stamp support, too. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: little typo
On Wed, Apr 09, 2008 at 08:57:55AM -0500, Brandon Black [EMAIL PROTECTED] wrote: On line 369 of ev.h in the latest CVS, EV_ASYNC_ENABLE is typo'd as EV_ASYND_ENABLE. thx, fixed. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: valgrind stuff
On Wed, Apr 09, 2008 at 05:34:22PM -0500, Brandon Black [EMAIL PROTECTED] wrote: My reading of that other thread I quoted is basically (a) the standard is self-contradictory I can't really read that from the thread, and the standard is certainly not self-contradictory, but certainly very hard to read in some cases (same thing was true when ECN was introduced). The posix manpage could be worded more verbosely, but it is otherwise not contradictory. Note that 0 indicates success (-1 indicates an error, and timing out is not a documented error either), so the standard unambigously requires revents to be initialised when poll returns 0. standards are not standard english prose, all thats required of them is being unambigious, not being easy, or obvious. (b) some systems definitely don't clear revents when they poll() returns zero I can't find anything like that in that thread, either, can you point out where in this thread it says this? All I can find is that *valgrind* is again buggy. Can you point out where in the thread those systems are mentioned= (what I'm seeing) Where do you see that revents is non cleared by poll? From what you said it seems that valgrind says uninitialised memory would be accessed, which is foremost a bug in valgrind. Did you really see that poll didn't clear revents? valgrind is *not* a real system, and it is not gfood for valgrind to flag corretc code as wrong, that would diminish it's usefulness. so if in fact it is only valgrind and not e.g. the syswtem you use it on then valgrind would need to be fixed. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: valgrind stuff
On Wed, Apr 09, 2008 at 06:56:22PM -0500, Brandon Black [EMAIL PROTECTED] wrote: I have different standards. No need to get personal with attacks on my standards. You said it is a moot point for you, I just pointed out that I have different standards of what is moot and what isn't. Are you too intolerant to allow me the right to have different standards? That would be rather poor of you. Nobody was attacking you, and there is no reason to react so childishly by accusing people of getting personal. I *did* ask you to provide evidence for your conclusions, and it would be far more helpful of you to answer those questions then reacting like you do just now. Your behaviour certainly doesn't seem to come from trying to fix problems, otherwise you'd explain how you came to your conclusions. I am interested in writing good software, reaching a goal, creating solutions. If it's a valgrind bug then fine, it's a valgrind bug. Well, it is a valgrind bug. I was initially confused by the thread you mentioned because it seemed to quote from the posix manpages, but the manpages are, in fact, unambigious. Look, either the change you applied to skip scanning revents on a retval of zero is a blind kludge or an optimization that happens to workaround a valgrind bug. If you think it's a blind kludge and its optimization value is dubious (or even negative), then by all means don't apply the workaround, nobody's forcing you. Again, I don't understand why you act so childishly. I asked you a number of questions on statements you said, which would help me decide what the best way to proceed would be. I don't see why you couldn't just be helpful instead of being obstructive. To make good decisions, I need knowledge. You made some statements about conclusions you made that I cannot follow. I asked you to explain your reasoning and the evidence you base your conclusion on, but so far, rhere is no indication that you would do so. Instead, you seemingly try to force a change by claiming it would be moot, it would be a performance optimisation, it would fix a real issue on some systems etc. etc. I am not inclined to make badly thought-out decisions just because somebody makes some claims that might turn out to be wrong. All I've done here is seen a valgrind output flagging a potential problem Well, thats much less than what you wrote in your earlier mail, so lets assume you exaggerated a bit to make the issue seem more important than it really was, to reach some goal. I don't see how that is any indication that I lack standards. Well, nobody accused you of lacking standards. Claiming indirectly as if somebody did is trolling, and this will get us nowhere, so stop doing it, or get ignored: there are people who have work to do, and part of that involves improving libev for the real world, and not make work around some obscure bugs in some memory chekcing tools. If you do care about quality, then help improve the tool you use and rely on - valgrind - don't try to push changes and workarounds into other projects by exaggerating evidence. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Latest libevent+libev package
On Sat, Apr 12, 2008 at 11:59:41PM +0800, JH [EMAIL PROTECTED] wrote: Sorry to disturb you. We're using memcached + libevent and today a friend told me there's libev. I saw the performance charts and am very interested in test driving libev. I only found http://dist.schmorp.de/libev/Attic/libevent-1.4.1-beta+libev-3.0.tar.gz but the latest libevent is 1.4.3 and latest libev is 3.2 (also the CVS bug fixes). Could you please update the libevent+libev package? I tried, but the changes are nontrivial and would boil down to a lot of work - however, does memcached really need the full libevent? wouldn't the libevent emulation inside libev work for it as well? Note that the libevent emulation isn't 100% - only the typical behaviour is implemented (for example, in libevent, the last event base created gets the signals, while in libev, it is always the default event loop, which is the first event base created by the emulation), so some work is expected for a program relying on libevent's idiosyncrasies, but that's true for libevent+libev as well. So in short, if memcached doesn't rely on libevent specifics such as the http and dns code, the libevent core emulation inside libev should suffice. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [ANN evdispatch]
On Fri, Apr 11, 2008 at 04:10:27PM -0400, Todd Fisher [EMAIL PROTECTED] wrote: I just wanted to announce a new library I created using libev and libcurl. It provides 2 interfaces; A C++ interface and a C/Ruby interface Hi, I had a very quick look at it, and only have a single comment: the configure script works like this: - run the libev.m4 stuff - run the libev configure script - make in libev Now, if you run libev's configure script you don't need to include the m4 macros, as the public headerfiles of libev have been carefully (painfully? I would really need a 64 bit type...) designed not to rely on configure information. Also, make'ing in a configure script is not that nice. So, either you should run configure/make but not include the m4 macros, OR you should neither confgiure not make in the libev subdirectory, but instead include the m4 macro and then add a rule for ev.o in your own makefile. (as it is, it will work, however) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
libev-3.3 release
I am pleased to announce libev 3.3. Distribution: http://dist.schmorp.de/libev/libev-3.3.tar.gz Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod This is a minor bugfix release, but there are a lot of minor bugfixes bug workarounds, mainly because of the feedback I received from many of you. - linux eventfd support, which greatly reduces ev_async latency. - ev_async_pending was broken. - new ev_async wrapper for ev++.h - inotify and epoll availability should be autodetected now when autoconf is not used (autoconf always overrides), which should simplify embedding even more. - new DEFAULT_UC macros that avoid checking wether the default loop was initialised already (but you have to make sure that ev_default_init is called before first use). - work arounds for realloc - libev will now use free on all platforms. - work arounds for many bugs in valgrind, one way or another. - use inlining in the header file with c99 compilers and gcc, which silences some warnings but should have little effect otherwise. Enjoy! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: libev-3.3 release
I am pleased(?) to announce libev 3.31. Distribution: http://dist.schmorp.de/libev/libev-3.31.tar.gz Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod The only change is a bugfix for the poll backend from Brandon Black that I considered important enough for an immediate release. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Trivial warnings nit
On Fri, Apr 18, 2008 at 11:16:43AM -0500, Brandon Black [EMAIL PROTECTED] wrote: At least for me using it embedded with my compiler/cflags/etc (which include -Werror, which is what makes it a pain why I compile on targets Well, specifying -Werror is a rather stupid thing to do (if it is gcc, it turns gcc into a non-conforming C compiler...), and certainly isn't supported by libev: libev cannot make workarounds for all existing compiler warnings, there are too many compilers out there and too many warnings that trigger on correct code. Since it is so trivial, I have little problems with applying this workaround, but in general, I'd like to avoid yntactical lutter that makes maintainance harder just to compile with a deliberately broken compiler. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: OSX kqueue support
On Tue, May 06, 2008 at 12:19:30AM -0400, Thomas Harning [EMAIL PROTECTED] wrote: Just wondering... has there been any testing done w/ OSX and kqueues? Yes. It 'looks' like libevent has kqueues working from their regression tests... but I'm not sure. Only with sockets. I just got a MacIntel w/ Leopard (10.5.2) running and wanted to see if I could get libev up and running at full speed... From what I was told(!), devices still don't work with 10.5, which makes kqueue useless as generic event model. Note that libev fully supports kqueue on OS X, it is just not suitable for a generic event loop. You can always create your own loop using kqueue with libev but then it is up to you to make sure you use only those fetaures of kqueue that happen to work with os x. If there's any unit tests or regression tests for libev, please send them my way and I can run/test them out... They are part of the EV perl module, available from the same place as libev. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [Libevent-users] FYI: libevent/libev benchmark updated for libevent-1.4.3
On Thu, May 08, 2008 at 12:03:06AM -0500, Dan [EMAIL PROTECTED] wrote: Think I tried Ev once, to many bugs, hell couldn't even set a timer within a timer as I remember, In no release ever was there such a bug. libev and EV are used in many production environments and projects, too and have proven their stability by now. FYI: This dan guy is not an unknown, he regularly trolls, and has proven many times that he has no clue of programming, how to pass arguments etc.. This is from his earlier mails: From: Dan [EMAIL PROTECTED] Date: Sun, 20 Apr 2008 01:55:04 -0500 (CDT) # Like your perl EV module but kinda pointless without letting us have args. # # need to do $blah-blah($a,$b,\%c,[EMAIL PROTECTED]); # # I notice new version out of libeventare you going to maintain this? # Like to make this my event library (So his main problem was not having a clue about the programming language he wanted to use, namely Perl). From: Dan [EMAIL PROTECTED] Date: Sun, 20 Apr 2008 23:39:56 -0500 (CDT) # Sorry I am abit of a noob to events still. I been doing alot of research # on what the fastest, best module would be to use and yours seems like it # would be by far the fastest and use the least memory. [...] # What I thought I would do is use your excellent module and use events. So back then it was an excellent module for you, that is, until I told you to read a good book about perl first. Apparently, you don't want to improve your programming skills, lieing about other people's work is enough for you. Try again. This EV stuff just meant to undermine the hardwork of the folks at libevent? No, you are just an idiot, and a bad liar and top. The benchmark document explains exactly how these timings were derived and how to reproduce them, including the source to the benchmark, exact version numbers for the libraires used, compiler flags etc., for everybody to verify. If you don't believe the numbers you can verify them yourself, as well as the validity of the benchmark numbers and the implementation. You are certainly not doing the libevent developers any good by trolling and spreading lies: I am sure they don't need the support of fanboys like you. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: new 4-heap code - please give it a try
On Wed, May 07, 2008 at 11:34:14AM -0500, Brandon Black [EMAIL PROTECTED] wrote: I've just tried it against my code, looks pretty good from here. My test suite passes with the new code, so no breakage. Yeah, and my test suite passed as well, the problem showed only with few timers :- The only performance-sensitive parts of my code that really exercise libev only use it for a small handful of watchers for UDP sockets (in the benchmark case, 3 UDP sockets). Even then, the runtime is dominated by things other than libev (mostly memory compare/copy operations). Hopefully. My designs usually try to optimise basic parts as much as possible (or sensible), so I can waste all that nice speed with slower perl code or so :) put too much faith in them. It definitely didn't seem to hurt though, even in my low number of watchers case. These are average seconds for the benchmark run (which will generate 1,000,000 socket events on one of the three sockets) for the two different versions, using EV_MINIMAL or not, sorted by runtime: 3.33 NORMAL: 17.54 3.33 EV_MINIMAL: 18.49 3.31 NORMAL: 18.49 3.31 EV_MINIMAL: 17.88 Thats interesting, especially that the MINIMAL timing and the 3.31 normal timings agree so much. But then if minimal on 3.31 makes such a large difference, it should make a similar difference on 3.33. So I guess stuff like cache colouring is really responsible for the difference. Still, the small number of timers case is not unimportant, at least it shows that in typical programs the difference isn't great. So your numbers are reassuring (I hope the bug didn't change the numbers much :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
How *I* would design a libevaio
Since I already wrote some aio framework and sue it a lot, but miss the ability to use it directly from C, here is how I would design it's API. Much of the fucntionality would be similar to what the IO::AIO,perl module uses, the C api would be similar to both the POSIX functions (just with a continuation/callback) and libev. See IO::AIO's functions here: http://pod.tst.eu/http://cvs.schmorp.de/IO-AIO/AIO.pm#FUNCTIONS Event loop ties It would not be tied to an event loop, not even ev. Currently IO::AIO offers a file descriptor the user has to poll for read, or ignore and call the processing hook regularly, allowing quasi-synchronous operation and independence of any particular event loop. In a new design I would offer this, but also optionally a callback, that clalbakc could then use ev_async for example, which is (sometimes) more efficient then polling a pipe. but no other event loop I know has something like ev_async, so offerign a file descriptor is a must. Result Processing result processing would be strictly synchronous and single-threaded. the user would have to call a function (e.g. evaio_poll). There would be an option to limit the number of results processed per evaio_poll call, and a limit on the overall time (resulting in lots of gettimeofday calls). See the support functions in IO::AIO. Threading it would use threading internally for most requests. The api would allow usage of overlapped I/O or aio_read/write functions internally (but doesn't need to be implemented thta way, so future expansion is possible). See CONTROLLING THE NUMBER OF THREADS in the IO::AIO documentation. There would be one, or two ways to handle aio requests: 1. simple posix-like wrappers, e.g. evaio_read (fd, offset, length, address, (callback, data)) evaio_fstat (fd, (callback, data)) evaio_stat (pathname, (callback, data)) evaio_link... and so on. A full list of functions I found a requirement for low-latency programming can be found in the IO::AIO document, 2. setup/queue primitives for special uses (which would look very much like ev, btw.), which require more work, but are slightly more flexible: evaio_req req; evaio_read_init (req, parameters); evaio_start (req); Sugar I found some additional primitives very useful, for example, grouping (see IO::AIO::grp in the above url), as well as being able to cancel requests in a defined way. In fact, I was close to separate the c parts of IO::AIO into a separate library a number of times, but the demand wasn't so high (for example, the deliantra game server which is mostly written in C++ simply calls out to perl for all I/O operations, which certainly was fast enough so far). Of course I also don't really have the time, thats why I wrote how I *would* design..., but I, too, would like to have something like that. As for windows compatibility, of course probelms start with stuff like evaio_stat and end at evaio_readdir. In fact, IO::AIO uses the same thread abstratcion as the BDB perl module (thread-pool for async berkeley db access), and while BDB works on windows, IO::AIO doesn't, as the differences in API are too large. The best one could do is probably return ENOSYS for almost all functions on windows (after defining ENOSYS probably :). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Libev leaks memory
On Thu, May 15, 2008 at 07:10:36PM +0900, hsanson [EMAIL PROTECTED] wrote: I am using libev to implement a media server and so far everything is smooth and easy. The only problem that I found is that libev seems to leak memory. It doesn't: Running this program under valgrind will give me errors about unallocated blocks. Not sure what an unallocated block is, but there is no such thing in the report you included. ==30474==definitely lost: 0 bytes in 0 blocks. ==30474== possibly lost: 0 bytes in 0 blocks. no memleaks. I tried searching the cause but I am not familiar with libev internals yet. Any tips are appreciated. In the report you included there is no memory leak. Did you misinterpret valgrind output? -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
valgrind is a tool
Sorry, I couldn't resist, but since valgrind plays such an enourmous role to many people (who don't even understand the valgrind output), let me just take note that the horrendous security disaster http://www.debian.org/security/2008/dsa-1571 was created because the debian openssl maintainer tried to silence all valgrind reports, which was successful, as he removed the code that randomised the random keys generated by openssl, therefore compromising all keys generated by openssl, openssh, openvpn, all certificates created etc. in the last years. so valgrind is a superb tool, but its just that. you still have to understand each and every issue, and not every report is a bug, just like not every report indicates a memory leak. one has to understand it to be able to make good use of it. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
libev-3.33 release candidate
Hi! since no new bugs have been reported for a while and it seems to work for my programs, I plan to do a 3.33 release soon. It would be nice if some of you could try it out as if it were the real release, I do not expect any changes (that are not to the documentation), but then, I made last-minute mistakes in the past... The candidate can be found here: libev-3.33.tar.gz There have been no bugfixes known to cause actual problems, but the heap is now a 4-heap by default, and the heap index is cached within the heap array, both of which make it much more cache-friendly. (and the implementations differ between EV_MINIMAL and !EV_MINIMAL, so if somebody uses EV_MINIMAL that would also be helpful). Thanks, I expect a release in a few days. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Hang in fd_ebadf function
On Fri, May 30, 2008 at 10:12:45AM -0400, Marc-André Cournoyer [EMAIL PROTECTED] wrote: Perfect, it works now w/ checking the EV_ERROR bit, thx Marc! No, it doesn't - if you get EV_ERROR for this case then your code is buggy - you *must not* have active watchers with illegal file descriptors. The fact that libev tries to work around your bug doesn't mean it works (in fact, you are relying on luck because this bug isn't 100% detectable in libev). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Hang in fd_ebadf function
On Mon, Jun 02, 2008 at 11:31:22PM -0400, Marc-André Cournoyer [EMAIL PROTECTED] wrote: What I'm doing is: if the EV_ERROR bit is set, close the connection right away. Which connection? EV_ERROR means the connection doesn't exist, so whatever you close, likely is something else, another bug. I'm also closing the connection if there's any error send- ing or recv-ing on a socket. Thats fine - you would not have to handle EV_ERROR if you did that (and are single-threaded), as send/recv gives you the same error. By it works I meant that it stoped hanging when there was an error on the socket before the send or recv. Yes, but your program is still buggy. What you did is trade a certain bug against a bug that occurs more rarely. Getting EV_ERROR is (in your case) a programming bug in your code, not something you can work around by closing some unrelated fd - it means you register a watcher on a fd that you cnanot register a watcher on, likely some that doesn't have any conenction. I mean, I could care less about your code, but not fixing the bug and relying on libev detecting the condition for you and hoping all is well asks for disaster. It is *much* better to fix your code instead. Let me know if you think I'm doing something wrong. You are fighting the symptoms, you are not fixing the bug. EV_ERROR means your code has a big bug somewhere. libev doesn't catch this bug with all backends, not can it work efficiently in the presense of such a bug. But I know there is still something weird in there when using Ruby threads, I'm trying to figure it out. If you are using threads, then all bets are off - libev cannot reliably detect this bug when threads are in use, and closing an fd that is already closed (the most likely cause for your EV_ERROR) means you *will* close an unrelated fd if some other thread created a new fd. This is an extremely big bug in your code. libev cannot reliably detect it, and you cannot work around it afterwards, you have to avoid it in the first place. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Libev on windows, binding to the D language
On Mon, Jun 02, 2008 at 01:57:57PM +1000, Hulbert Chris [EMAIL PROTECTED] wrote: Hi all, Note sure whom you replied to, or why you apparently quoted your own mail. CAUTION: This email and files included in its transmission are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. Unfortunately, you sent it to a public mailing list. Pretty stupid in the first place. If you receive this email in error, please advise us immediately and delete it without copying the contents Since I assume you want the mail to stay as confidential as possible, I will delete it now, as requested. contents are also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner. It is your fault for sending your mail to a mailing list - I am not responsible for your actions, nor am I responsible for cleaning up after you. If your really want to send mail to the list, then you need to: - get rid of silly, idiotic, and threatening disclaimers. - take responsibility - if you send a virus, you clearly are responsible for that. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Binding Libev to Digitalmars' D
On Tue, Jun 03, 2008 at 02:08:46PM +1000, Chris Hulbert [EMAIL PROTECTED] wrote: When it runs, I get the following error: Assertion failure: '(libev only supports socket fds in this configuration, ioctlsocket (anfd-handle, FIONREAD, argp) == 0)' on line 710 in file 'ev.c' Windows is completely incompatible with the posix model of having readyness notifications - only sockets work, and evry badly at that. It is extremely unlikely that non-blocking code works as-is on windows. libev works around *some* of those issues (for example, the CVS version works around windows' non-blocking connect failing to wake up the program on errors), but of course not on others (close() not working for sockets, connect returning EINPROGRESS meaning it failed, send not supporting partial writes, only being able to do one non-blocking operation at a time and more and more etc.). It's a completely, utterly, broken platform. So in general, code on windows needs largish'ish changes independent of libev to have any chance of working reliably. Since I suspected lots of grief otherwise, libev actively checks that the file descriptor you pass in belongs to a socket. Note that: a) low-level operating system handles are not file descriptors b) the raw socket functions return operating system handles The reason for this is that libev offers the _same_ API on windows as on portable/standards compliant operating systems: you have to apss in file descriptors on unix, you have to pass in file descriptors on windows. The most likely causes for the above error are either: a) you pass in an operating system handle instead of a file descriptor b) you pass in some file descriptor that isn't a socket (e.g. standard input) Can anyone suggest where I'm going wrong - are my #define statements wrong in the myev.c ? The defines can make libev use posix-select or winsock select, but the API is the same: you need to pass in file descriptors, and those file descriptors must belong to sockets. (And again: libev does what it can, but your code likely has to change for windows, too). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
possible new timer type - any users?
I had an idea for a new timer type. It would basiclly work like ev_timer without repeat, with the following differences: - the actual delay value is constant for a group of such objects (there would be two objects: ev_timeout_queue and ev_timeout (naming subject to change) - you would specify a constant timeout value to use for all timeouts in the queue, but could then put many individual timeouts into the queue). - removing and inserting a timeout into such a queue (resetting the timeout) would be *very* fast O(1), on the order of 5-10 machine instructions or so. The motivation for this very specific timer type would be that, in the real world, it often is the case that a lot of timers have the same timeout value. A typical example would be a busy transaction server which would have activity-timeouts for any socket conenctions, and maybe individual timeouts per transaction/request. It is likely that all those time-outs will have the same delay value, which makes them prime candidates for the proposed new timer. Using ev_timer involves and O(log n) operation for each insert/remove (in practise, if one uses ev_timer_again and if the timeout is much longer than the again-call-interval, as is typical in real-world cases, then the n above is lower than the totral number of timers, but still, the operation is costly). Is anybody besides me interested in such a timer? Also, the ev_timeout name would be fitting, but too simialr to ev_timer, and ev_const_timeout and ev_const_timeout_queue is way too long - any ideas on a good name? ev_ctimeout, ev_ctqueue? -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: libeio, Windows (was: Binding Libev to Digitalmars' D)
On Mon, Jun 02, 2008 at 10:57:07PM -0600, Tony Arcieri [EMAIL PROTECTED] wrote: Also, any plans on providing a C++ interface to libeio? I can slap an extern C somewhere in the header file. Actually, done already, so the c++ interface would be the same as the C interface for now :) project I'm interested to integrating it into and it'd be great to have a C++ face on it. Well, C++ is fully compatrible with C libraries. What kind of functionality would you like to have? Would you want to be able to specify objects and methods instead of a callback and a data pointer? This could be done trivially using wrapper functions (without variadic templates, unfortunately, all provided mosty manually). If you want, I could craft an example wrapper function that could be adapted. Instead of: eio_unlink (/etc, 0, cb, this); You'd write this in C++ (example): eio_unlink (/etc, 0, this, class::method); Or, if we moved the priority to the back and have it a default value: eio_unlink (/etc, object, class::method); this would be slightly more natural then the C interface. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: libeio and plattform specific aio
On Tue, Jun 03, 2008 at 11:51:47PM +0200, Aleksandar Lazic [EMAIL PROTECTED] wrote: what do you think, will libeio be able to use the 'best' aio for the plattform, or are there all only part of the solution? It would be, but you need to be careful - linux doesn't have working AIO for normal files - the libc on linux emulates it using threads, and libeio's threads are much lower on resource usage and are also faster. solaris has kernel-aio, but it also uses threads, so it's not clearly better. in fact, you lose scheduling control when using them. something similar is true for kqueue - you might actually get better performance and more control via threads. windows would be kind of closest :) so while libeio certainly could transparently use native aio, this currently isn't on my priority list, as on most platforms it will just use threads anyways or will not work very well. if somebody sent a patch for some platform and maintained it, that would of course be very welcome (especially if some benchmark showed how this affects resource usage and efficiency), but it is likely too early to use native aio on most operating systems. kqueue is probably closest to something like that, followed by windows. note, however, that rarely-used features in kqueue have been broken in 100% of the cases in the past, so don't get your hopes up. (of course, threading is usually broken on bsd's as well, so it might not be much worse). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Windows Compilation problem
On Wed, Jun 04, 2008 at 04:19:36AM -0700, Matt Tolton [EMAIL PROTECTED] wrote: I'm having some trouble getting libev to compile on windows. I am embedding it as recommended. Here are the errors I receive initially: for the NFDBITS issue, you could try out current CVS, which should contain an (untested) workaround for that. the io.h issue is surprising - with my microsoft sdk, I get those definitions when I include windows.h with WIN32_LEAN_AND_MEAN - why it would require an additional io.h include for you is puzzling. I poked around and discovered that the io.h header has the unreferenced functions. I added that in my ev_cpp.c file above the ev.c include. This reduced the errors to the following: I think that's the way to go for the moment. lib\ev/ev.c(773) : warning C4806: '==' : unsafe operation: no value of type 'boo l' promoted to type 'int' can equal the given constant Hmm, that might actually be a real bug... (it is of no consquence as long as libev is used correctly, though). lib\ev/ev.c(981) : error C2664: 'ioctlsocket' : cannot convert parameter 3 from 'int *' to 'u_long *' This is also a bug - could you check out CVS, which will have a possible fix for that as well in a few minutes? (It also doesn't affect correctness, when it compiles, as unsigned long is compatible to int on windows for the values used). According to the docs, the NFDBITS problem should be fixed by defining EV_SELECT_USE_FD_SET, which seems to be defined automatically for windows. It should, but the recent workaround for non-blocking connects apparentlsy reintroduced the dependency on NFDBITS. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: High-performance Windows Sockets Applications ;-)
On Wed, Jun 04, 2008 at 11:37:50AM -0400, Thomas Harning [EMAIL PROTECTED] wrote: and that might well be true... to get perfromance out of windows, use threads. preferably thread pools. I think they mean that you want to use separate threads for computation and data communication Exactly: use threads (and blocking operations) and not non-blocking operations. I think I recall finding that IOCP either uses a thread-pool or interrupts currently executing code for its callbacks... so you'd have IOCP perform data management and on completion do the minimum amt of work (queue up the data to be processed). Note that IOCP are the wrong approach to sockets - they work fine for files, but not for sockets. Window smight force you to use them for sockets to get performance, but thats another issue. This doesn't quite fit into libev's workflow directly (booo!), though one 'could' create some interesting layers... It's not libev's workflow, it's the workflow of about every other OS out there. It's standardised by POSIX as well. One should be careful before punishing the majority of well-designed platforms just because of the atrocity of one platform with a business agenda of being incompatible. Ex: something like libeio's interface could take advantage of some items transparently, or a layer for libev that handles data transport and alerts you to readiness for data available in filled buffers or buffers have room to put data (kinda like the bufferevent abstraction...). Not quite - libevent's buffer thingy is the right thing here - it could do the right thing on unix and abuse iocps on windows because its the only thing that works well there. I cannot imagine that this interface would be even remotely similar to libeio's api, though, the problem is just too different. I also think it is pointless to implement such an abstraction just because of a single abysmally broken platform (glib does that for example, and the result is quite portable, and quite horrible). If one restricts oneself to sockets, however, the other approaches possible with winsockets should be explored as well - sockets *do* support the posix model, just the mapping is non-trivial (yeah, you need threads, and a window handle) (but the mapping from the broken windows select to posix semantics is quite horrible as well, so it doesn't mean it isn't doable). For libev, using async notification for sockets is definitely more useful and has more future then forcing everybody to use some api only required for windows performance. If somebody made himself the work to implement a specific winsockets backend that used async notification and needs extra configuration in the form of a window handle, that would be nice. And it would mean that applications can take advantage of it without sacrificing speed and good design just because of windows. windows *is* a second class citizen, and performance on it is quite unimportant, as long as you can write programs that work efficiently elsewhere and still work correctly on windows. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Bug in select_modify?
On Sun, Jun 08, 2008 at 01:24:31AM -0700, Matt Tolton [EMAIL PROTECTED] wrote: In getting libev running on windows, I think I may have found a bug in the select_modify() function in ev_select.c. What you actually found is yet another bug on that horribly broken platform. Well spotted (none of my programs aggressively re-use fds :) an array for its fd set, and it doesn't check to see if the fd is already in the set when you do an FD_SET. Right, because FD_SET is guarenteed to not to add an fd twice even as per msdn docs - of course, the implementation is broken as always. Since microsoft will unliekly bother to fix their pile of bugs, libev has to yield again. kept returning EBADF, but libev couldn't find the bad fd. I imagine that most fd sets use bitvectors or something so this isn't a problem (not that I know much about this stuff). Well, the point of having those macros is to not have to know about how they are implemented - the berkeley sockets interface guarantees that FD_SET only adds the fd once to the set (after all, thats a set), and microsoft claims to follow this. So the problem is not how its implemented, but the fatc that it is simply broken - the whole point of having FD_SET was to not have that bug in the first place. *sigh*. I made the following modification to select_modify (sorry it's not in diff format...I'm sure you can see where it goes): Indeed, for such small patches, it's ok (you could have formatted it better, though...) I will try to add somrething like that that only punishes windows to libev. Thanks a lot for catching this and analysing the situation! It seems that something like this should be added to the real libev source. You could also, of course, use the FD_ISSET macro. This would probably be more foolproof, but I'm guessing it would be slower (not that we'll get much performance out of windows using select() anyway). oev - nev changes should catch 100% of the transitions for each fd, except after a fork, which doesn't matter as this is not an operation windows supports in a sensible way. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Binding Libev with Digitalmars' D on windows
On Fri, Jun 06, 2008 at 04:10:45PM +1000, Chris Hulbert [EMAIL PROTECTED] wrote: If anyone's interested, some details are here, and i'd be interested to hear comments on how i've structured the code: http://splinter.com.au/blog/?p=15 That doesn't seem to be very difficult (when one knows this beforehand :), so this inspired me to mention _open_osfhandle in the win32 section and the following section: A typical way to use libev under windows is to embed it (see the embedding section for details) and use the following Fevwrap.h header file instead of Fev.h: #define EV_STANDALONE /* keeps ev from requiring config.h */ #define EV_SELECT_IS_WINSOCKET 1 /* configure libev for windows select */ #define EV_STAT_ENABLE 0 /* no stat() availble */ #include ev.h And compile the following Fevwrap.c file into your project (make sure you do Inot compile the Fev.c or any other embedded soruce files!): #include evwrap.h #include ev.c I will look into probably disabling EV_STAT_ENABLE on win32 by default for the next release (you are not expected to have to do that yourself). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Binding Libev with Digitalmars' D on windows
On Mon, Jun 09, 2008 at 04:02:52PM +0200, Marc Lehmann [EMAIL PROTECTED] wrote: I will look into probably disabling EV_STAT_ENABLE on win32 by default for the next release (you are not expected to have to do that yourself). Bollocks, it is supposed to work - I have checked in a patch to libev that should enbale ev_stat watchers - could you give it a try and report back wether they compile? -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Error when configuring libeio
On Thu, Jun 05, 2008 at 08:51:23PM +0300, Paul Colomiets [EMAIL PROTECTED] wrote: I'm getting this error, while configuring: configure: error: cannot find install-sh or install.sh in . ./.. ./../.. Bigger log below. Can anybody help me? Yeha, follow the hints: libtoolize: `/usr/share/aclocal/libtool.m4' libtoolize: `/usr/share/aclocal/ltoptions.m4' libtoolize: `/usr/share/aclocal/ltversion.m4' libtoolize: `/usr/share/aclocal/ltsugar.m4' libtoolize: `/usr/share/aclocal/lt~obsolete.m4' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. /usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG /usr/share/aclocal/smpeg.m4:13: run info '(automake)Extending aclocal' /usr/share/aclocal/smpeg.m4:13: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal [EMAIL PROTECTED] libeio]$ ./configure configure: error: cannot find install-sh or install.sh in . ./.. You need an install (and working!) libtool, automake and autoconf to configure the CVS tree. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: libeio, Windows
On Thu, Jun 05, 2008 at 11:07:37PM -0600, Tony Arcieri [EMAIL PROTECTED] wrote: I am sorry, but we must be talking past each other. libeio cannot give you readyness notifications, and using it for I/O on sockets is simply broken design. Yeah, as I said before: my bad, libeio does not fit the Proactor pattern You can repeat it as many times as you want, and it is still wrong: it doesn't have anything to do with patterns or suitability. libeio is well suited for files and other async I/O sources and libev is well suited for sources that are non-blocking. They don't fit any patterns because patterns have nothing to do with it. Both fit the proactor pattern just fine. You are confused by too many patterns and too little reality - patterns is how you structure your program, libeio is a library you can use for that. It can make sense to use the proactor pattern for both files and sockets for example, but the underlyig implementation should be different. It has little to do with fitting - if your problem fits in the proactor pattern, then by all means use it. But do not use libeio for socket I/O. This really has nothing to do with patterns, but with reality of doing things the right way... -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Error when configuring libeio
On Mon, Jun 09, 2008 at 08:21:54PM +0300, Paul Colomiets [EMAIL PROTECTED] wrote: P.S.: There are no Makefile.am. Is it OK? (I'm actually not familiar with automake and co.) No Makefile.am should have been there (but wasn't), I added it to cvs now, thanks for spotting this! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
libev-3.42 has just been released
I am pleased to announce libev 3.42. Distribution: http://dist.schmorp.de/libev/libev-3.42.tar.gz Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod?pathrev=rel-3_42 Changes: http://cvs.schmorp.de/libev/Changes?pathrev=rel-3_42 This release almost exclusively contains workarounds for windows and bugfixes for libev limited to windows, most of which have been found by a libev users trying out libev in new and interesting compilation environments :) For non-windows users there is little reason to upgrade. - work yet another bug in windows select() function by passing in the write fd set as except fd set and interpreting exceptions as writable. - work around FD_SET overflowing the fd_set when adding the same fd multiple times. - make ev_select compile when NFDBITS isn't defined. - make fd_intern compile on win32 in all supported configs. - ev_ebadf contained a bug causing it to incorrectly report user errors. - (hopefully) make ev_stat work on native windows. Enjoy! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Few suggestions
On Tue, Jun 17, 2008 at 03:45:07PM -0700, nsf [EMAIL PROTECTED] wrote:
1) Include pkg-config .pc file to source distribution.
patches welcome.
2) I wanted to compile my project (which is using libev) with -Wall and
without any warnings, but there is few bad macros in libev.h. So, I was
forced to remove all these macros and change them to ugly code.
You can see in this commit what I mean:
http://github.com/nsf/bmpanel/commit/60f74645be5e234f778d43621cbfc59d9f9d6cd8
(just search with browser string ev_io_init and look around)
first, please read the section on warnings in the libev manual.
you didn't just change your code to just ugly code, you took (potentially)
*working* code and *broke* it, invoking undefined behaviour.
silencing warnings does not at all mean you fixed a problem - using the
macro creates correct code, your workaround silences the compiler and will
result in crashes (or worse) when you use a compiler intelligent enough to
optimize away your buggy code.
To fix bugs, one still has to use one's brain, which is why the compiler
issues warnings and not errors - because it cannot for sure know wether
this is an error or not.
As you can see from this example, it is easy to silence a compiler warning
by introducing bugs that the compiler cannot warn about anymore.
I'm not a pro in C, but why are you using these type conversions in
macros:
The ev_watcher cast is *required* for proper operation as the active and
pending members are not the same ones that libev uses internally.
The void * cast is used to silence an (in the case wrong) warning in gcc.
the latter is indeed not required by the C language rules (but if your
goal is to have less warnings, you should embrace them), but the former
certainly is.
---
#define ev_timer_set(ev,after_,repeat_) do { ((ev_watcher_time
*)(ev))-at = (after_); (ev)-repeat = (repeat_); } while (0)
---
They will work without them.
That's a blatant lie :) They are _broken_ without them. Get a
(necessarilys, as average books don't cover this) good book about C and
learn about aliasing rules.
And also there will be no warnings in -Wall mode.
Great. Compiler silenced, code broken.
Do yourself a favour and learn from the debian security disaster, where
exactly the same thing happened: warning/error message silenced, security
completely broken.
You have to *understand* error messages, not rearrange and break code so
it becomes too complex for the compiler to diagnose any problems.
I'm using gcc 4.3.0.
gcc-4.3.0 is one of the compilers just intelligent enough in some cases to
actually break the intended meaning of your code (by optimising away your
= 0 assignments, as nothing accesses those fields).
If you want your code to work, you have to use -fno-strict-aliasing with
that version of gcc (because it isn't proper C anymore), or use the
provided macros, which are type-safe.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=/_/_//_/\_,_/ /_/\_\
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: libev and DUMA
On Tue, Jun 17, 2008 at 09:24:45AM -0700, Michael Leib [EMAIL PROTECTED] wrote: Has anyone ever used libev along with the D.U.M.A. -s Detect Unintended Memory Access (http://duma.sourceforge.net/) lib? This is a requirement for what I am working on and libev is just hanging on the ev_io_init macro when used along with DUMA. Wihout it, everything is cool. If it works without it, you should probably contact the makers of that software, I am sure that hanging is not what is supposed to happen. it could be a bug in libev, but i am sure even if it is, then duma should make sure libev crashes (that is what it claims) and not hang. but most likely, it's a problem in duma itself, or somewhere else. it's kind of interesting, as the ev_io_init macro doesn't do all that much. if it is hanging, a backtrace might be useful. if you include any header files from duma, maybe they interfere with ev.h in some way. if you are using the intel c compiler, look no further, it doesn't have a working preprocessor, which causes a lot of problems. it could also conceivably be a bug in your code itself, although it would probably involve catching SEGV and doing really werid things :) and last not least, maybe it's not really hanging in ev_io_init and your interpretation of the gdb(?) backtrace(?) is flawed(?). Just wonderring if anyone else had this combo working together and, if so, was there something that had to be changed in oder for it to do so. Currently, I'm stumped. last I looked, libev works fine with libefence (of which duma suppsedly is a descendant), and I wouldn't expect there to be anything special to be done to be able to use it (libev doesn't play any dirty tricks and is not supposed to contain any code that could rightly or wrongly trigger a problem with something like duma). so by all means, use duma on it and investigate any issues - you will find a real bug in libev OR a real bug in duma, a 100% win-win solution :- -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Binding Libev with Digitalmars' D on windows
On Tue, Jun 10, 2008 at 10:07:45AM +1000, Chris Hulbert [EMAIL PROTECTED] wrote: I've just downloaded the latest from CVS and uncommented the '#define EV_STAT_ENABLE 0' line from my myev.c as you requested, and i get the following compilation errors when using the DMC compiler: ah, you need to include whatever defines struct _stati64 on windows first, still :/ I will add an include to the next release of libev (sorry for the late reply, btw. and thanks for testing it), when I found out what to include exactly. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Few suggestions
On Wed, Jun 18, 2008 at 03:39:24PM -0700, nsf [EMAIL PROTECTED] wrote: Well, I have already sent a patch to mailing list. I hope you didn't miss it. I just want to make sure you got is, so here is the link: http://lists.schmorp.de/pipermail/libev/attachments/20080617/73c9e0ca/attachment.bin I didn't miss it, but I only saw it after you sent it. you didn't just change your code to just ugly code, you took (potentially) *working* code and *broke* it, invoking undefined behaviour. As long as my code is giving me *exactly* the same behaviour as macros code, my code isn't broken. Welcome to the world of stupid programmers then. The fact that your broken code happens to result in a working program with *your* optimisation setting and *your* compiler and *your* architecture and *your* operating system and *your* compiler version doesn't make it correct to *anybody* else. Sure, you might claim that, but thats just plain stupid, your code isn't valid C (because it relies on uninitialised data happening to be 0), end of story. The fact (or non-fact) that you might have luck with it with your config doesn't make it non-broken. It is possible that on some configurations on some stupid compilers my As I mentioned, the compiler you use (gcc) is so stupid in some cases. Future versions will very likely be so stupid in many more cases, as global optimisation techniques become even more global (intra-file). code is broken, but my software isn't portable. It is linux/gcc/x86 software. Your software is broken on linux/gcc/x86 already. That's a blatant lie :) They are _broken_ without them. Get a (necessarilys, as average books don't cover this) good book about C and learn about aliasing rules. Btw, timer-related variants actually purely identical in asm. Because you are lucky and don't trigger the optimisation. Your program is still broken. Anyway, I don't want to argue with you. It's your right to think your way. If it isn't possible for you to make changes, I'll leave hacks in my code or eventually I will change the library. It is certainly possible for me to make changes, but the changes you suggest break the code for everybody. I would be stupid to apply your buggy changes. This is not a question of it being possible, but a question of it not being sensible. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Binding Libev with Digitalmars' D on windows
On Tue, Jun 10, 2008 at 10:07:45AM +1000, Chris Hulbert [EMAIL PROTECTED] wrote: I've just downloaded the latest from CVS and uncommented the '#define EV_STAT_ENABLE 0' line from my myev.c as you requested, and i get the following compilation errors when using the DMC compiler: it seems windows needs a few more include files - can you tets current cvs? I additionally include time.h, sys/types.h and stdio.h on windows now. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Duma and libev, cont'd....and a leak found
On Thu, Jun 19, 2008 at 01:22:20PM -0700, Michael Leib [EMAIL PROTECTED] wrote: working as I have found what I belive is a memory leak in libev when dealing with signals and the deafult loop. It's not a leak, search the list archives for details if you are intersted. 1) The signals array is never freed So is your code section and your data section. Are these leaks? No... 2) Pending signal events are not restored to to system default handling when the default loop is destroyed. Yes, signals are only reported to the default loop, but they are a process-global resource. I hope this e-mail brings out a shortcoming and provides a solution. I would not have caught this without duma. Careful reading of the libev docs or looking at the list archives would have helped as well. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: ev_timer problem
On Wed, Jul 02, 2008 at 01:46:36PM +0300, vvvua [EMAIL PROTECTED] wrote:
Default loop also maintain an async io on sockets. The program
architecture is designed with only one point of realisation of async
calls - in ev_loop (loop,0) with default loop;
It is totally unclear to me what you mean with async io - i assume this
is something in your program?
First, i create a timer at 45sec.
After each callback, i am trying to set timer on 5 seconds, but timer
waits 45 seconds.
You should probbaly show the code for that.
TimeSockMapper()
{
memset(tm,0,sizeof(ev_timer));
memset(repeat,0,sizeof(ev_tstamp));
You do not need to zero-initialise the watcher structures, this will only
bloat your code.
void timeout_cb(EV_P_ struct ev_timer *w_, int revents)
{
int cfd;
struct TimeSockMapper * w= (struct TimeSockMapper *)w_;
struct LocalOpcodeData * ldata = (struct LocalOpcodeData *) w-defPoint;
cfd=w-fd;
ev_timer_stop(loop,(ev_timer * )w);
No restart here.
void set_timeout(int fd, long long seconds,LocalOpcodeData *ldata)
{
TimeSockMapper *mtm=new TimeSockMapper();
mtm-repeat=0;
mtm-fd=fd;
mtm-defPoint=ldata;
ev_timer_init ((mtm- tm), timeout_cb, seconds, 0.);
ev_timer_set ((mtm- tm), seconds + ev_now (loop) - ev_time (), 0.);
ev_timer_start (loop,(mtm-tm));
No restart here either.
If the timer indeed doesn't restart as you want, then you should show us
the code that actually resets the timer and restarts it - make sure you
stop the timer before modifying it, or, even better, use ev_timer_restart
and a suitable restart interval.
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=/_/_//_/\_,_/ /_/\_\
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: ev_timer problem
On Thu, Jul 03, 2008 at 02:47:20PM +0300, vvvua [EMAIL PROTECTED] wrote: First, i create a timer at 45sec. After each callback, i am trying to set timer on 5 seconds, but timer waits 45 seconds. And where do you stop the timer? Quite obviously, taking a timer, handing it over to some event library and then re-intiialising it's memory block will at best lead to funny effects, and at worst to crashes. I don't see in all your snippets where you stop the timer before you reinitialise it. Note that this would be slow anyway, it is much faster to just restart it, but stopping, reinitialising and starting works fine as well. not stopping it, rowing it over with new data and starting it again will of course corrupt internal structures. Without code, there is little to tell however, but I still don't see where you stop the timer and reinitialise it. If the timer indeed doesn't restart as you want, then you should show us the code that actually resets the timer and restarts it - make sure you stop the timer before modifying it, or, even better, use ev_timer_restart and a suitable restart interval. ev_loop is in different thread. Is this a problem? No way to tell without all the code (and I'll probably not bother going through all of it - you are expected to debug your thread problems yourself). It is fine as long as you follow the rules laid out in the documentation (search for the THREADS section). Your question is a bit puzzling, however - did you even read the documentation? If not, why not? If yes, what's unclear about it? -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
libev-3.43 has just been released
I am pleased to announce libev 3.43, which is a pure windows-only release. Distribution: http://dist.schmorp.de/libev/libev-3.43.tar.gz Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod?pathrev=rel-3_43 Changes: http://cvs.schmorp.de/libev/Changes?pathrev=rel-3_43 This release exclusively contains compiletime bugfixes for libev on windows. For non-windows users there is little reason to upgrade. - libev uses the corretc includes for _stati64 - io.h is now included from ev.c Enjoy! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: ev_timer problem
On Mon, Jul 07, 2008 at 03:54:21PM +0300, vvvua [EMAIL PROTECTED] wrote: When ev_loop finishes to maintain all registered timers, it waits on epoll, and epoll waits for events from sockets. When i register a new timer in the second thread, ev_loop still waits on epoll... Of course, this is not allowed. To resolve this problem i created a heartbeat timer in the main thread. It's not a solution, your program will just crash at different times now. Get a book about threads programming and elarn about race conditions, and how to avoid them (e.g. by using a mutex). Also refer to the threads section in the libev manual. In short, if you don't lock the loop yourself, then the only thing you can do in another thread is to call ev_async_send. Another solution - is to set timeout on sockets read/write operations. Not sure what that solves, but you need to understand thread programming and use proper locking to avoid races, otherwise your program runs into undefined behaviour (most likely, crashes). This is all documented in the libev documentation, however. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: 2 problems with AnyEvent::DNS
[this is off-topic for libev but relates to one of my other projects, namely AnyEvent - I have replied off-list] -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: event.h conflict between libev and libevent
On Tue, Aug 12, 2008 at 12:16:40PM -0400, Michal Nowak [EMAIL PROTECTED] wrote: Do you thing it could be possible to avoid such conflict on upstream basis? Unlikely, the conflict is by design. Giving example, to install event.h, ev.h and ev++.h to /usr/include/libev by default? That would break applications that expect to find it as event.h (basically all libevent applications). On Tue, Aug 12, 2008 at 01:06:27PM -0400, Michal Nowak [EMAIL PROTECTED] wrote: - Matt Tolton [EMAIL PROTECTED] wrote: Why not just leave out event.h? That's just for libevent compatibility. Thanks, that was my original decision. Why not do it like other distributions such as debian, where the common header files are installed as alternatives, or optionally? event.h is an alternative to the libevent event.h, it's not an unrelated header file, it serves the same purpose in both libraries. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: cast question, again
On Fri, Aug 29, 2008 at 05:11:23PM +0200, Egon Eckert [EMAIL PROTECTED] wrote: sorry about introducing the ever-appearing aliasing-warnings theme :)... Can someone, please, explain why *not* doing the cast in following macro definition: not doing the cast accesses the at member of *ev (with unknown type, but usually the type isn't ev_watcher_time), doing the cast accesses the at member of the ev_watcher_time struct overlaying whatever ev's real type is. since all the remaining code also accesses the ev_watcher_time.at, leaving out the cast allows the compiler to reorder code because can assume they are not the same lvalues. (in practise, this doesn't happen between source files yet, but it does happen within the same source file). In c++, one could use an explicit static cast to typecheck, but not in C. (in c++, of course, one could simply subclass...) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [eio] where do the callbacks come from?
On Sat, Aug 30, 2008 at 01:09:54PM +0200, ryan dahl [EMAIL PROTECTED] wrote: Are the eio_cb callbacks made during eio_poll() or from the worker threads? Always from eio_poll, i.e. always synchronous to whatever thread calls eio_poll. It should also be permissible to call eio_poll concurrently from multiple threads, as eio_poll properly locks the result queue for each request, although nobody has tested that so far :) (it is even permissible to recurse into eio_poll from a callback, this ahs been tested). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [eio] readahead
On Mon, Sep 01, 2008 at 05:29:25PM +0200, ryah dahl [EMAIL PROTECTED] wrote: I'm trying to understand your emulation for readahead() in libeio. It doesn't seem that the eio_buf that is being read into is ever referred to again. Correct. Is the idea that calling pread() will cache the file anyway? The idea is to emulate the linux readahead(2) syscall, which does the same thing, it reads the data but doesn't use it/transfer it to the app. What about using fadvise? Indeed, what about it? fadvise isn't blocking anywhere I know of (in fact, fadvise most often simply does nothing), so it is outside the scope of libeio. (this might change - I was under the impression that close, futime and fstat were non-blocking, too, but linux proved me wrong :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: subclassing the watcher
On Thu, Sep 11, 2008 at 03:03:59PM +0400, Kandalintsev Alexandre [EMAIL PROTECTED] wrote: According to manual its possible to write this code(example from section ASSOCIATING CUSTOM DATA WITH A WATCHER: You must have misread something, the documentation never tells you that using a different type for a watcher argument works. ev_io_init (stdin_watcher, stdin_cb, /*STDIN_FILENO*/ 0, EV_READ); stdin_watcher is not of type ev_io, you have to use stdin_watcher.io here if you want that. ./test.c:17: error: ‘struct my_io’ has no member named ‘cb’ ./test.c:17: error: ‘struct my_io’ has no member named ‘fd’ ./test.c:17: error: ‘struct my_io’ has no member named ‘events’ How to fix this problem? Use the correct types - ev_io_* requires an ev_io * as first argument, as in the example above. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: subclassing the watcher
On Mon, Sep 15, 2008 at 08:42:51AM +0400, Kandalintsev Alexandre [EMAIL PROTECTED] wrote: if you want that. Ok, but later in the documentation you cast ev_io to my_io: Yes I do, but that's fine, because there is a cast there. Instead of specifying the address directly, you could also cast my_io to ev_io * or so - be creative, it's C. I think this is wrong becouse w_ points to my_io-io and not to my_io, isn't it? It's correct, because casting my_io-io to struct my_io gives you the address of my_io in the example - read about how C layouts structures and you will see why this works, and what to do in the cases when it doesn't work (which is also exemplified in the same chapter). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: cast question, again
On Sat, Sep 27, 2008 at 03:47:31PM +0200, Alejandro Mery [EMAIL PROTECTED] wrote: I'm have this issue too, compiling my project with -Werror -Wall -W (by policy) That's a pretty braindamaged policy: firstly, it means your compiler is no longer capable of compiling standard C, but only some badly-defined dialect of it, secondly, it means each compiler version will change the language you are working with. You may do that, of course, but you will not eb able to use libraries wirtten in standard C. warning: dereferencing type-punned pointer will break strict-aliasing rules and compiling stops.. but This is most likely a compiler bug - do you still get that with current versions of gcc? (self-timeout)-at = 0.0; (self-timeout)-repeat = (timeout); without the cast, compiles flawlessly. It compiles, and is broken, yes, as it allows the optimiser to drop your assigments now, as per ISO C language rules. The reason those warnings are warnings is that the compiler cannot know for sure. While some warnings are very solid, this warning has seen a lot of bugs in it's history, and is far from perfect, as is evident. (But this has been explained in other threads). there is any decent way to solve this? Easily, compile your project as standard C, the language libev was written in. Your mail is like I try to compile libev with my pascal compiler, but it gives me errors, how do I resolve that? and the answer is well, use a C compiler. This is so obvious I wonder why it comes up again and again. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
libev-3.44 has just been released
I am pleased to announce libev 3.44. Distribution: http://dist.schmorp.de/libev/libev-3.44.tar.gz Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod?pathrev=rel-3_44 Changes: http://cvs.schmorp.de/libev/Changes?pathrev=rel-3_44 This release contains no bugfixes, and only minor enhancements: - embed watchers now automatically invoke ev_loop_fork on the embedded loop when the parent loop forks. - new function: ev_now_update (loop). - verify_watcher was not marked static. - improve the associating... manpage section. - documentation tweaks here and there. Enjoy! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: multiple signals per watcher
On Tue, Sep 30, 2008 at 02:06:00PM +0200, Alejandro Mery [EMAIL PROTECTED] wrote: I have an ev_signal watcher upon SIGTERM|SIGINT, but I just noticed ^C What should SIGTERM|SIGINT be? OR'ing two signal numbers together does not usually result in anything useful, and certainly is no magical way to store two numbers in one number. Since signal numbers are usually small integers, you could probably roll your own bitfield, via 1USIGINT etc., but that isn't portable either. Since those symbols do not come from libev, this is also outside the scope of libev - check your system dcoumentation on the values of the SIGxxx symbols. is not been catched by this watcher, only SIGTERM... are multiple signals on the same watcher supported by libev? The documentation seems absolutely clear to me - what part of the ev_signal documentation did you find unclear and needs improvement? btw, the example http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#Examples-4 has a wrong _start() and SIGTERM is not mentioned. Indeed, thanks! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: multiple signals per watcher
On Tue, Sep 30, 2008 at 04:59:08PM +0200, Alejandro Mery [EMAIL PROTECTED] wrote: please ignore this mail, I ran out of coffee :-\ I don't know why I thought signum was a bit mask Ah oh, feel free to ignore my reply then :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: libev issue due to inotify bug
Before 2.6.25, inotify did not notify the user in case a file st_nlink reached 0 (IN_ATTRIB event). This is problematic for application that wish to be notified of file deletion although they still have an open file descriptor on the deleted file (they never get any notification about the deletion). In response to this, libev has been modified (in CVS) to avoid using inotify on kernels 2.6.25. The version check is somewhat ugly, it would be nice if somebody else looked over it. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
libev issue due to inotify bug
Yoann brought the following issue to my attention, which affects libev
ev_stat watchers when a file gets deleted which is still open.
- Forwarded message from Yoann Vandoorselaere [EMAIL PROTECTED] -
Subject: libev issue due to inotify bug
From: Yoann Vandoorselaere [EMAIL PROTECTED]
Date: Mon, 13 Oct 2008 17:25:51 +0200
To: [EMAIL PROTECTED]
X-Mailer: Evolution 2.22.3.1
Hello Marc,
We are currently porting Prelude-LML (a log analyzer) to use libev
ev_stat notification in place of GAMIN/basic polling, and wanted to let
you know about an inotify bug that impact vanilla Linux kernel 2.6.25.
Before 2.6.25, inotify did not notify the user in case a file st_nlink
reached 0 (IN_ATTRIB event). This is problematic for application that
wish to be notified of file deletion although they still have an open
file descriptor on the deleted file (they never get any notification
about the deletion).
More information about the kernel issue is available here:
http://www.ussg.indiana.edu/hypermail/linux/kernel/0711.3/1208.html
It would be great to add some test case to libev.m4 so that it check
whether the current inotify version is buggy or not (some Linux
distribution use kernel 2.6.25 but included a patch for this issue).
You can test the problem using the following code:
static void libev_check_cb(struct ev_loop *loop, ev_stat *st, int revents)
{
int *inotify_work = st-data;
*inotify_work = TRUE;
}
static void libev_check_timer_cb(struct ev_loop *loop, ev_stat *st, int revents)
{
ev_unloop(EV_A_ EVUNLOOP_ALL);
}
static void inotify_ok(void)
{
int fd;
char fname[1024];
struct ev_stat event;
struct ev_timer evt;
int inotify_ok = FALSE;
snprintf(fname, sizeof(fname), %s/test-inotify.XX, P_tmpdir);
fd = mkstemp(fname);
if ( fd 0 ) {
fprintf(stderr, error creating unique temporary filename:
%s.\n, strerror(errno));
return;
}
ev_timer_init(evt, libev_check_timer_cb, 1, 1);
evt.data = inotify_ok;
ev_timer_start(ev_default_loop(0), evt);
ev_stat_init(event, libev_check_cb, fname, 1);
event.data = inotify_ok;
ev_stat_start(ev_default_loop(0), event);
unlink(fname);
ev_loop(ev_default_loop(0), 0);
if ( ! inotify_ok ) {
fprintf(stderr, WARNING: buggy delete detection.\n);
}
close(fd);
}
Hope this help,
Regards,
--
Yoann Vandoorselaere [EMAIL PROTECTED]
- End forwarded message -
--
The choice of a Deliantra, the free code+content MORPG
-==- _GNU_ http://www.deliantra.net
==-- _ generation
---==---(_)__ __ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=/_/_//_/\_,_/ /_/\_\
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: double stop loops and watchers
On Mon, Oct 20, 2008 at 01:42:13PM +0400, Kandalintsev Alexandre [EMAIL PROTECTED] wrote: Is it safe to call ev_*_stop on stopped watcher? As I understood it's safe. Yes. Is it safe to call ev_unloop on stopped loop? I didn't find any suggestions in docs. There is no such thing as a stopped loop - if you mean calling ev_unloop from outside ev_loop, yes, that's allowed (and has no effect). BTW, I think your method to detect the kernel version2.6.25 is correct I didn't find any points where linux kernel exports version except struct utsname. Thanks :) It's disgusting to have to parse the version string :/ -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: bug in epoll affecting libev
On Tue, Oct 28, 2008 at 12:45:07PM +0300, Kandalintsev Alexandre [EMAIL PROTECTED] wrote: I just found another bug in epoll Did you try to contact kernel developers about this problem? The kernel developers are not interested in fixing epoll. (I tried a year ago for similar issues, fork races, and the samba and postfix authors were similarly being ignored, so on linux, we have the choice between the totally misdesigned epoll API or select/poll, I wish for somethign comparatively sane as kqueue). I realised we need some kind of token protection anyways in case of fork - basically, with epoll, you have to recreate the epoll handle in both parent and child after a fork (or do even slower things before the fork). Now, libev did explain that you can get spurious notificagtions (solaris event ports cause those too, for example), the crucial difference is that I thought it would be possible to cope with them easily in application code, but recently realised you can't do that portably for nonblocking connects (maybe not even nonportably - I don't know how to check for whether a connection is currently in progress or not except by trying another connect or so). To me, the remaining question is just whether I should extend the ANFD structure with 32 bits of generation count, or whether I can go with the 8 bit currently implemented (which are free): Extending a structure from 8 to 12 bytes sucks, especially on ia32. I also think about about forcing the use of pthread_atfork (or the internal __register_atfork) on linux, to catch forks for the parent (the child is easy, getpid has virtually no cost, so forcing a getpid call per loop iteration would not concenr me at all, but that doesn't work for the parent process). I also still think of ways on how to avoid the epoll set recreation in the parent (for 1 fds this means 10001 syscalls...), but I can't come up with anything that would be practically useful. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Stat changes not picked up on MacOSX 10.5.
On Tue, Oct 28, 2008 at 01:38:33PM +0200, Graham Leggett [EMAIL PROTECTED] wrote: Using the code below, (which has been badly garbled by your mailer and doesn't compile) I am expecting the event loop to run the callback when I touch or edit the file to which I am pointing (directorry-directory), but for some reason this doesn't happen. Do you really store the path of a _file_ in a variable named _directory_? If yes, then it is a mystery. ev_stat_init(directory_watcher, watch_directory_cb, directory-directory, 0.); What's the value of directory-directory and which file/path do you actually change? TIMEOUT, 0.); What's the value of TIMEOUT? Is it larger than the default stat interval (which is ~5s)? -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
libev-3.48 has just been released
I am pleased to announce libev 3.48. Distribution: http://dist.schmorp.de/libev/libev-3.48.tar.gz Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod?pathrev=rel-3_48 Changes: http://cvs.schmorp.de/libev/Changes?pathrev=rel-3_48 Changes include: - libev now tries very hard to work around problems with fork and spurious event notifications by using a 32 bit generation counter to a) verify that an event is uptodate and b) to recreate the kernel state from scratch when a spurious event is received. - further optimise away the EPOLL_CTL_ADD/MOD combo in the epoll backend by assuming the kernel event mask hasn't changed if ADD fails with EEXIST. - use memset to initialise most arrays now and do away with the init functions. - expand time-out strategies into a Be smart about timeouts section in the dcoumentation. - fix a bug where ev_default would not initialise the default loop again after it was destroyed with ev_default_destroy. Enjoy! If anybody is interested in the gory details of why this was necessary with epoll, I can expand the topic in more detail. What prompted the change was the realisation that you cannot work around the breakage from the child process after a fork, and spurious notifications can be generated in cases where they are hard to work around for the application. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: libev-3.48 has just been released
fashon is just an efficiency problem, not a corretcness issue). While most API's do require some work after a fork, they will not generate spurious events, and you can always fix it in one process without the queue becoming unusable in all processes. Summary: the problem with epoll is that a fork instantly makes ALL epoll sets used by the process unusable, with no way to recover from that, in both parent and child, except by throwing away the epoll sets and creating them from scratch, *iff* one is able to detect the problem. If anything is unclear, feel free to ask for a more verbose explanation. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: win32 question
On Mon, Nov 10, 2008 at 06:32:41PM -0700, Roger Pack [EMAIL PROTECTED] wrote: trying to compile rev [based on libev] for mingw in windows, I sent it fd 3 [an accepting socket] It is unlikely that 3 was a valid fd then. Assertion failed: (libev only supports socket fds in this configuration , ioctlsocket (anfd-handle, FIONREAD, arg) == 0), file ../libev/ev.c, line 729 Indeed, libev verifies that the app passes in a valid fd, and fails with an assertion otherwise. where apparently anfd-handle was equal to 1956 [calling ioctlsocket with 3 works] If you can call ioctlsocket with 3, then it most likely isn't a valid fd, as ioctlsocket does NOT accept fd's, it wants socket handles. Not sure if this is the right fix, but here's an attempt: The API requires file descriptors on every platform, including windows. The fix is to pass in file descriptors, not os-specific handles (if you want to work on a fix, you should research the list archives, also, the documentation has some information on windows). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: mingw compat note
On Mon, Nov 10, 2008 at 10:35:08PM -0700, Roger Pack [EMAIL PROTECTED] wrote: This overcomes compile errors similar to: You forgot to atcually mention the error messages in your mail (you only included a harmless warning message). Which errors do you actually get? -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: if there's ever time...IOCP possible?
On Wed, Nov 12, 2008 at 01:17:46PM -0700, Roger Pack [EMAIL PROTECTED] wrote: I wonder if it would be possible to add IOCP (to emulate event driven architectures) to libev. No, it isn't - iocp's are not powerful enough to emulate the posix event api. http://www.eggheadcafe.com/software/aspnet/32292639/integrate-windows-io-com.aspx seems to explain how. the problem is that the famous passing in a zero byte buffer trick a) isn't supported by the windows api and b) often fails in practise. besides, performance with a medium number of file handles is likely to be much better with select (or the new wsapoll). with a higher number of handles, iocps would (if possible) perform better. the job of libev is to support the posix model on windows, so programs can be ported well, at a performance cost because of the extremely braindamaged and windows api. the goal is to be compatible, not to have windows-specific hacks that complicate libev user programs. besides, there is no point in wasting ten times the amount of code in getting marginally better performance for that platform. Twould be nice to have a mechanism in win32 to overcome the FD_SETSIZE limitation. There is, it's called #define? If you had read the libev documentation, as you were told a number of times already, you'd know about that. Here's to wishing :) Thoughts? I wish people would search the list archives and read the manual first. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: web site down?
On Sun, Nov 16, 2008 at 08:53:54AM -0800, Eric Brown [EMAIL PROTECTED] wrote: The web site is down now? And I noticed a week or two ago that the documentation wouldn't load from the web -- this is down now too (at least the link I have bookmarked). It seems to work fine for me, also for a few others I have asked. Are you sure this isn't a local issue? Also, freshmeat is usually quite picky when sites become unrachable :) Anybody else has problems? I see now that the build system builds a man page, but it would be nice if it build the html docs as well. Those are what I'm used to referring to. Actually, the build system doesn't build the manpage, it's included in the tarball. Including the html docs would blow it up too much - wget is your friend? -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: web site down?
On Sun, Nov 16, 2008 at 12:43:24PM -0800, Eric Brown [EMAIL PROTECTED] wrote: Interesting, both are up for me now. I'll do some more digging if it happens again. And I'll pull a copy of the html local. Cheers, our backup nameserver was down for 12 hours today - maybe you didn't wait long enough for your resolver to pick up the other address? (and that wouldn't explain any earlier problems, as both servers were running for 200 days, without any known outages). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
libev-3.49 has just been released
I am pleased to announce libev 3.49. Distribution: http://dist.schmorp.de/libev/libev-3.49.tar.gz Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod?pathrev=rel-3_49 Changes: http://cvs.schmorp.de/libev/Changes?pathrev=rel-3_49 There have been no bugfixes in this release. The only major change is that inotify is now used even on older, known to be buggy, kernels, but only as a hint. Also, libev now has a small list of known to be good filesystems where inotify is known to work, and will use inotify as a hint only on other filesystems (such as NFS). The documentation has been updated regarding the dangers of using stat watchers on networked file systems. Enjoy! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Unit tests, sample code, mirrored site?
On Wed, Nov 19, 2008 at 03:42:18PM -0800, Jim Lloyd [EMAIL PROTECTED] wrote: However, I was surprised that there doesn't seem to be any unit tests included in the tar ball. Are there any unit tests? If so, can they be made available? There are no unit tests, The canonical testsuite for libev is part of the EV perl module. And what about other sample code? The documentation references several full applications and libraries making use of libev, which is a lot of sample code, exercising all sorts of configurations as well, in several languages, too. Also, software.schmorp.de seems to be slow from my location in San Francisco. You need better internet then - software.schmorp.de is connected very well, and network slowness is likely a local problem at your side. Mirroring on the other hand will not fix any slowness introduced by the dynamic nature of the pages. Is the site mirrored in the U.S.? Nope. No doubt for fear of colliding with anti-terror and weapon trade laws or so. Finally, the short example program given near the beginning of ev.pod does not compile as is. The first line of main currently reads: ev_loop *loop = ev_default_loop (0); Thanks, I have updated the documentation :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: EV_ERROR for ev_io events?
On Mon, Nov 24, 2008 at 04:49:36PM -0800, Eric Brown [EMAIL PROTECTED] wrote: I had been requesting EV_ERROR events on my io watchers -- mostly because that's what I used to do years ago when I had to manually create FD_SETs. Of course, I don't recall ever getting an ERROR event ever. errors are errors, they are no events, and you can't request them. And, I noticed libev just added an assertion that EV_ERROR events weren't valid for io events (ev.c:2130). Absolutely - libev will signal *errors* that way, there is no such thing as an error event. I'm guessing this is not a bug in libev and some man page somewhere says ERROR events will never be generated on io events? An error occurs, it is not an event: For example, the select function could fail with an error of EBADF, which would cause libev to check every submitted fd and tell the watcher. Right now, EV_ERROR always means you have a bug in the program using libev. Which is why requesting an error event makes no sense - it's kind of askign for please put a bug in the function calling ev_io_start. Out of curiosity, does the OS ever generate ERROR events for any type of selectable file descriptor? If so, when? No, the OS api's (like select or poll) cannot even generate error events. They can flag an error, but there is no such thing as an I/O error when askign for readyness notifications, as libev doesn't do any I/O. Maybe you confuse error with the except fd set in select? -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Fwd: EV_ERROR for ev_io events?
On Mon, Nov 24, 2008 at 05:58:42PM -0700, Roger Pack [EMAIL PROTECTED] wrote: I believe on windows it reports error selectable when there's an error No, the select fucntion cannot report error events in any way - you also probably confuse that with the except set, which serves no actual purpose on standards-compliant systems, and is mapped to EV_WRITE on the buggy windows platform (as it errornously signals connect readyness that way). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Erratic timers
On Sat, Nov 29, 2008 at 02:45:24AM +0200, Graham Leggett [EMAIL PROTECTED] wrote: to achieve is a timer that gets called immediately, and then repeating every 2 seconds after that. ev_timer_init(msg-timer.timer, watch_timed_message_cb, 0., 2.); ev_timer_start(msg-c-s-e-loop, msg-timer.timer); I expect the timer to fire in 0. seconds, and then start repeating every 2. seconds after that. That's what it will do. Instead the timer fires off once immediately, and then nothing. Most probably you stop the timer, or exit the program or the event loop, or something else. Can anyone confirm whether there are further steps that I need to take before this will work? There are no further steps necessary - most likely the further steps are the problem. If you post an example that compiles I can probbaly tell you what's wrong. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: my bug or libev's? when multi-thread and multi-loop
On Tue, Dec 02, 2008 at 04:46:32PM +0800, CodeAll [EMAIL PROTECTED] wrote: queue. Each of the worker has a ev_base_new(0). What is an ev_base_new(0)? and which version of libev are you trying this with? 1. I kill -SIGSEGV the process, gdb it, found it's busy on epoll_wait() The process still exists after SIGSEGV? that means you have a signal handler for it - what does it do? 6. I guess, that maybe something wrong when i using libev in mutil-thread env, or some fd are wrongly closed, or some fd are missing but events continue coming. That's most likely a bug in your program - make sure you never call functions on the same event loop from different threads, OR use locking. There are also other rules to follow, such as stopping your event watchers before freeing them etc., but this probably isn't the problem here. Sorry for my english. I find your english quite good :) -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: my bug or libev's? when multi-thread and multi-loop
On Tue, Dec 02, 2008 at 04:59:11PM +0800, CodeAll [EMAIL PROTECTED] wrote: 1. a little like http://lists.schmorp.de/pipermail/libev/2008q4/000453.html, but i tried poll backend, has problem too Not at all, actually. 2. when i generate a lot of request from 10 client, the server choose to not keepalive(one request per connection), but the system is reusing fd. Like, fd = 14 are closed, after a well, fd = 14 are used again. I see this in io_cb()'s debug info and strace's epoll_wait(xxx) Not sure whwt the relevance of that is, but in general, you have to stop a watcher when you close a fd. The documentation epxlains this in detail. However, this would not cause the problems you see. It really looks much more like you accessed the same event loop form multiple threads, or had another bug in your program, such as not initialialising the file descriptor number properly. Without an example program showing the issue or a minimal amount of additional info (libev version, strace), there is nothing more that I cna say. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: How do I cancel a timer?
On Mon, Dec 15, 2008 at 06:34:10PM +0200, Graham Leggett minf...@sharp.fm wrote: Can someone confirm first of all for me that ev_timer_stop is the correct way to cancel a timer? Yes - are you sure you don't start it again, or modify it in illegal ways? The docs make no mention of how you destroy a timer, only how you might create one or reset one. Because destruction is on your side of the API - libev has no facilities to create or destroy timers, that's what the application does. The documentation mentions exactly, however, when you can safely reuse the watcher structure for something else, which is what you seem to want. But remember, creation and destruction _for watchers_ is completely outside the libev API, only _event loops_ can be created and destructed. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / p...@goof.com -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Poll / Kqueue on Mac OS X
On Mon, Dec 15, 2008 at 11:23:31AM +1300, Space Ship Traveller space.ship.travel...@gmail.com wrote: I haven't benchmarked kqueue. This wasn't really about benchmarking - it was more about scratching my particular itch. I don't expect to ever have a huge number of fds to query, so at this point it is a bit inconsequential. Then using the select backend (or select) is likely to be faster anyways, and certainly much more portable :) select is usually faster than poll or other event mechanisms on most unix systems, too, if you have few and low file descriptors. I was very confused about the original behavior of kqueue. I just expected it to work as you indicated. Same here, that's why I lost so many words about it in the libev documentation. It would be nice if apple at least admitted to it in their documentation, i.e. kqueue only works for sockets, poll too, and we give a shit about fixing it :) Nothing in the documentation indicates otherwise. Yes, and that despite this being a well-known bug for years now. If you have all this energy, why not file a bug report. I don't use apple, and my experience with bug reports is that apple classifies them as non-public and forgets about them. Happened to all bug reports I or other people filed about these kind of problems, which includes more mundane bugs such as the broken-till-unusability i18n support and so on. Besides, it's not as if these bugs weren't well known by apple and had been reported many item in the past by people. It's kind of frustrating to file bugs just to see them disappear without any indication of apple even trying to do something. I'm bringing the issue up further with other developers on the darwin mailing list. I'll end up filing a bug report when I have more information and can provide a good report to Apple. Sure, but don't get frustrated if it gets blackholed, too - it's just how apple treats customers and developers. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / p...@goof.com -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: How do I cancel a timer?
On Tue, Dec 16, 2008 at 01:11:24PM +0200, Graham Leggett minf...@sharp.fm wrote: What I found I had done was initialised the timer twice. It seems that You can initialise the timer as many times as you want, as long as it isn't started. Although this is completely obvious (when you start a timer, obviously you can't just reinitialise the memory it uses), this is also mentioned very strongly in the manual. when this happens you have to stop the timer twice, or a single stop of the timer isn't effective. No, you simply have a bug in that case - you must not wipe out data structures that are in use, obviously. But remember, creation and destruction _for watchers_ is completely outside the libev API, only _event loops_ can be created and destructed. What I meant by destroy a timer is make sure this callback is never executed, because the memory beneath this is about to be freed. stopping it, as documented, will do that. At the moment, I am using ev_timer_stop() for this, and as long as I don't initialise the same timer twice, it seems to work. you can initialise the timer as many times as you want. you should find the bug in your code where you initialise a *running* timer again, which of course overwrites the data structures that are already in use. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / p...@goof.com -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: How do I cancel a timer?
On Fri, Dec 19, 2008 at 01:00:53PM +0200, Graham Leggett minf...@sharp.fm wrote: In theory, it shouldn't matter how many times you init the timer, a stop should stop it. Unfortunately, the real world works diferently than your theory, and the designers and authors of libev opted to folow a theory that closely matches reality, which fortunately wasn't your theory, which turns out to be unreasonable to implement. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / p...@goof.com -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: How do I cancel a timer?
On Fri, Dec 19, 2008 at 08:44:07PM +, James Mansion ja...@mansionfamily.plus.com wrote: because the design decision to have the multiple-init bug undetectable is effectively made. I'm just objecting to Mr Lehman's characteristically condescending and heavy-handed 'its not possible'. You'd be well-advised to read what I wrote. I explicitly wrote that the only methods to do so are requiring initialisation, or remembering the address of the watcher structure in some other way. While it might be possible that there is yet another variant (that isn't just a play on those two principal ideas), nobody so far came up with one. So if it *is* possible, then please state how. I skipped the rest of your e-mail and will likely do so with future e-mails as you are making your e-mails needlessly hard to read, despite being asked to format them in a readable way. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / p...@goof.com -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Detect when a file has been recreated using a stat watcher
On Mon, Dec 22, 2008 at 08:11:57PM +0200, Graham Leggett minf...@sharp.fm wrote: I tried this out on MacOSX 10.5, and found that monitoring ctime for file rotation changes were giving me lots of false positives (the file wasn't rotated at all, but every few seconds I was detecting changes). Yes, likely. st_ctime Time when file status was last changed (inode data The fact that ctime is updated on write() means that in theory, it cannot be used to detect file rotation. Just fyi: write *may* update the ctime, but doesn't do so in every case. It will likely do so in your case, however, as the size changes. I don't understand why it can't be used to detetc logfile rottaion, though? The ctime changes, too, with logfile rotation. There is also a stat64 structure, with higher precision on the file times, as follows: Please note that the *structure* has more space for this, but most filesystems do not actually support fractional times. So using stat64 doesn't magically give you higher accuracy. This second stat64 definition would imply that last status change and file creation (what I am looking for) are two separate things. Absolutely. But the ctime likely changes on file creation, or the size, or something else (such as the inode number). This all depend son how your logfiles get rotated - the file might get trucnated, deleted or somethign else might happen. My question is, is libev using the stat64 structure by way of comparison? No. And it wouldn't help your case unless you require the logifle to be on a specific filesystem supporting higher resolution timestamps. And even then, the higher resolution might sitll just be centiseconds or so. All this doesn't help you. The documentation (that you somehow fail to know, for inexplicable reasons) explains this case in mroe details and offers ways to implement this properly in your app. Is there a way for me to detect whether the stat or the stat64 structure is in use at a given time? No, that usually depends on how libev was compiled. Note that stat64 on most unices doesn't have a higher resolution, as stat already provides that, and stat64 is only for LFS. some systems (freebsd for example) sanely default their compilation environment to lfs, others (debian) inexplicably default to 32 bit and try to patch eahc and every app to separately enable lfs, which would presumably give you struct stat64. Is there a cross platform method to determine file rotation, by looking at the attr and prev variables returned by a stat event? Yes, but for some reason you claim it wouldn't work. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / p...@goof.com -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Detect when a file has been recreated using a stat watcher
On Tue, Dec 23, 2008 at 08:21:59PM +0200, Graham Leggett minf...@sharp.fm wrote: This all depend son how your logfiles get rotated - the file might get trucnated, deleted or somethign else might happen. So I should be looking at the size of the file, rather than the ctime of the file? I don't know, it depends entirely on how you define logfile rotation, which probably relies on whatever program does the actual rotation. a specific filesystem supporting higher resolution timestamps. And even then, the higher resolution might sitll just be centiseconds or so. All this doesn't help you. The documentation (that you somehow fail to know, for inexplicable reasons) explains this case in mroe details and offers ways to implement this properly in your app. Maybe I am looking at different documentation to you. No, you are just being difficult. We were talking about timestamp resolution, and what to do about it. And this is cetrainly being explained in the docs. The headings I see are ABI Issues (Largefile Support), Inotify and It might help to read more than just the headings. The special problem of stat time resolution. But there it is. The word rotate doesn't appear at all in the docs I am reading. I was replying to you talking about stat time resolution, and even quoted it, and even *you* quoted it, and then completely ignored it, claiming it has nothing to do with logfile rotation. Think before replying. Is there some other docs that I should be reading but am not aware of? No, you might be well-advised, however, to actually read the e-mails you read and the replies you get. Much less embarrassing. Is there a cross platform method to determine file rotation, by looking at the attr and prev variables returned by a stat event? Yes, but for some reason you claim it wouldn't work. So far I was led to believe that ctime can be used to detect file rotation, but the manpage for stat, and the code that I have in testing contradict this. It can, indeed, as it changes whenever the logfile gets rotated. Other things might change, too, such as the filesize, or the inode number, all of which would be hints that the logfile actually was rotated. If you are looking for a logfile rotation watcher in libev, then sorry, there isn't one, you still have to know what you are doing. Should I be using the file length instead? I don't think so - but it all depends on how you define it. Note that the only sure way of detecting logfile rotation in the general case is to let the program that rotates the log tell you. Eberything else is just heuristics. Note that, if you get more than a log message per second, then ev_stat likely isn't the most efficient way to detect that. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / p...@goof.com -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
libev-3.51 has just been released
I am pleased to announce libev 3.51. Distribution: http://dist.schmorp.de/libev/libev-3.51.tar.gz Documentation: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod?pathrev=rel-3_51 Changes: http://cvs.schmorp.de/libev/Changes?pathrev=rel-3_51 Release Highlights: - a number of bugs (one likely causing freezes) in the inotify backend have been found and fixed. - libev now falls back to select on OS X, as OS X 10.5 has a broken poll in addition to broken kqueue. - libev can now, on msot platforms, be compiled without a dependency on librt, by using a direct syscall invocation. - ev++.h now supports some forms of functors, by defaulting the method callback to operator (). Enjoy! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / p...@goof.com -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: Detect when a file has been recreated using a stat watcher
On Wed, Dec 24, 2008 at 12:40:46PM +0200, Graham Leggett minf...@sharp.fm wrote: I don't know, it depends entirely on how you define logfile rotation, which probably relies on whatever program does the actual rotation. As in the file gets deleted and/or truncated, and the event driven application watching the file gets notified by some mechanism that this has happened. Well, the ctime would likely change in those cases, as well as (likely) the inode number and (likely) the size, all of which could be detected via a stat watcher. We were talking about timestamp resolution, and what to do about it. And this is cetrainly being explained in the docs. Er, no, I think you have misunderstood my question. No, you completely midrepresent your e-mail, and that's no fun. I am not talking at all about timestamp resolution, You *were* talking about stat time resolution. Both inotify and kqueue can (apparently) detect file deletion/renaming events, Firts of all, no, they can't, at least not with certainty. This detection only works on some filesystems for example. although it seems that libev does not (yet) expose these events libev *caqnnot* expose these events as such because a) libev tries to be reliable and b) libev is a portable library, and the only thing available portably is stat. libev is *not* a wrapper around inotify, it only *uses* inotify to implement its (portable) stat watchers, and it only uses inotify as a hint mechanism (and in this case it actually does check for file deletions). So if you want to write an OS X only program, then you should be free to use kqueue, similarly for gnu/linux, but it's not acceptable for libev to become, say, a linux-only library. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / p...@goof.com -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
