On Sun, Nov 04, 2007 at 09:56:44PM -0800, Scott Lamb [EMAIL PROTECTED] wrote:
returning from event_loop, leaving the app unclear on what has happened
and what to do.
In any case, you can get the same behaviour as libevent by calling unloop
in case of an error, so the interface is
On Sun, Nov 04, 2007 at 10:04:05PM -0800, Scott Lamb [EMAIL PROTECTED] wrote:
Realistically, I think unit tests and bug reports/workarounds are about
the only reason to blacklist specific event dispatchers. select() sucks,
but well, that's why it's at the bottom of the list, right?
There is a
Marc Lehmann wrote:
On Sun, Nov 04, 2007 at 09:56:44PM -0800, Scott Lamb [EMAIL PROTECTED] wrote:
returning from event_loop, leaving the app unclear on what has happened
and what to do.
In any case, you can get the same behaviour as libevent by calling unloop
in case of an error, so the
On Sun, Nov 04, 2007 at 05:19:36PM -0800, Christopher Layne wrote:
On Sun, Nov 04, 2007 at 05:04:25PM -0800, Scott Lamb wrote:
* timers are managed by a priority queue (O(1) for important operations
as opposed to O(log n) in libevent, also resulting in much simpler
code).
In
On Sun, Nov 04, 2007 at 09:47:59PM -0800, Christopher Layne [EMAIL PROTECTED]
wrote:
What is my program supposed to do? It can't distinguish them, and the
correct behavior in each of these conditions is totally different. Also,
in the program I'm thinking of, libev chose to kill this file
Marc Lehmann wrote:
Hi!
On tuesday, I sent mail about various problems with libevent and its
current API as well as implementation. Unfortunately, the mail has not yet
shown up, but fortunately, it has been superseded by this one :)
In that mail, I announced that I will work on the
On Sun, Nov 04, 2007 at 05:04:25PM -0800, Scott Lamb [EMAIL PROTECTED] wrote:
* multiple watchers can wait for the same event, there is no limitation
to one or two watchers for signals and io.
Could you give me an example of where that is important?
Mostly in environments using some form
On Mon, Nov 05, 2007 at 02:42:16AM +0100, Marc Lehmann wrote:
On Sun, Nov 04, 2007 at 05:19:36PM -0800, Christopher Layne [EMAIL
PROTECTED] wrote:
Not to put on my O-face, but binary heap insert is *average* O(1). There
should be a performance win for libevent, when it comes to timer
On Mon, Nov 05, 2007 at 02:42:16AM +0100, Marc Lehmann [EMAIL PROTECTED]
wrote:
However, libev has an interface (ev_timer_again) that incrementally
updates the heap. Also, for repeating timers in general, there is no
removal/insertion but only an incremental update.
Oh, and sorry for always
On Sun, Nov 04, 2007 at 06:00:56PM -0800, Christopher Layne [EMAIL PROTECTED]
wrote:
My point was that an event_del() on an event which has been called before it's
timer has expired *or* an event_add() with a new timer will require
reheapifying
atleast part of the timer heap.
Hmm, I do not
On Mon, Nov 05, 2007 at 02:46:36AM +0100, Marc Lehmann wrote:
On Sun, Nov 04, 2007 at 04:09:08PM -0800, Scott Lamb [EMAIL PROTECTED]
wrote:
Have you seen the new Linux timerfd API? Where available, you can wait
for CLOCK_MONOTONIC and CLOCK_REALTIME events independently. Beats
heuristics,
Marc Lehmann wrote:
That seems rather undesirable for many applications.
Well, its arguably better than libevents behaviour, which is simply
returning from event_loop, leaving the app unclear on what has happened
and what to do.
In any case, you can get the same behaviour as libevent by
Scott Lamb wrote:
* What's your use case for ev_loop_new() and ev_loop_default()'s bitmask
of allowed implementations?
libevents unconditional use of getenv raised concerns with me and
apperently some users on this list, too, so this is one way to disable
this (EVMETHOD_ANY instead of
On Sat, Nov 03, 2007 at 09:15:07PM +0100, Marc Lehmann wrote:
snip
In that mail, I announced that I will work on the problems I encountered
in libevent (many of which have been reported and discusssed earlier on
this list). After analyzing libevent I decided that it wasn't fixable
except by
On Sat, Nov 03, 2007 at 03:45:39PM -0700, William Ahern [EMAIL PROTECTED]
wrote:
A good itch, indeed.
I am currently working on integrating all modules from libevent, so it
becomes a full libevent replacement (and it already runs all of the
testsuite that doesn't require access to internals).
15 matches
Mail list logo
