On Tue, Sep 09, 2008 at 04:48:40PM -0500, Andrew Troschinetz wrote:
> Hi all,
>
> I'm just getting started with libevent and I was wondering how I might
> implement a simple deadline timer with it.
>
> I'd like to be able to use do something like:
>
> void do_something(...) ...
> deadl
On Tue, Nov 13, 2007 at 06:27:58PM -0800, William Ahern wrote:
> > event_set(ev, fd, EV_READ | EV_PERSIST, read_cb, obj);
> > event_add(ev, &timeout);
> >
> > read_cb() will be called whenever a read event happens, and it's timeout
> > as passed to event_add() will be reset to the original
1. Make EV_PERSIST reschedule timeouts automatically.
2. New function: timeout_schedule: (nothing really new within it, just
modular wrapping of timeout rescheduling).
3. New macro: evutil_timercpy: tv_dst = tv_src in one line type deal;
3. Regression tests for persistent timeouts, include read/
As it is, EV_PERSIST is somewhat obtuse when trying to use it in combination
with EV_READ or EV_WRITE while still handling timeout events. The standard
idiom is basically:
if (select_epoll_etc_indicates_something)
do_something_and_add_fd_back_to_something_set();
else if (time_since_last_so
==00:00:00:08.662 19894== 64 bytes in 1 blocks are definitely lost in loss
record 4 of 7
==00:00:00:08.662 19894==at 0x4A06B92: malloc (vg_replace_malloc.c:149)
==00:00:00:08.662 19894==by 0x4A06C06: realloc (vg_replace_malloc.c:306)
==00:00:00:08.662 19894==by 0x4C24E16: min_heap_rese
On Mon, Nov 12, 2007 at 06:38:33AM +0100, Marc Lehmann wrote:
> On Fri, Nov 09, 2007 at 12:39:37AM +0100, Hannah Schroeter <[EMAIL
> PROTECTED]> wrote:
> > I see less problems with the writing away of the data sucked from the
> > web servers, as most Unix like systems write stuff asynchronously, s
event_del() calls event_queue_remove(base, ev, EVLIST_TIMEOUT).
-cl
Index: event.c
===
--- event.c (revision 515)
+++ event.c (working copy)
@@ -815,7 +815,6 @@
while ((ev = min_heap_top(&base->timeheap))) {
Index: test/Makefile.am
===
--- test/Makefile.am(revision 515)
+++ test/Makefile.am(working copy)
@@ -31,6 +31,6 @@
test: test-init test-eof test-weof test-time regress
verify: test
- @./test.sh
+ @$(srcdir)/te
On Sat, Nov 10, 2007 at 06:49:58PM -0800, Christopher Layne wrote:
> On Sat, Nov 10, 2007 at 06:44:12PM -0800, Christopher Layne wrote:
> > 11. here's the funny part: evsignal_process() increments event_count_active
> > - but since our
Here's a better patch:
This
On Sat, Nov 10, 2007 at 06:44:12PM -0800, Christopher Layne wrote:
> 11. here's the funny part: evsignal_process() increments event_count_active -
> but since our
should be:
evsignal_process() adds the internal event to the active queue as normal.
before we call event_pro
[ WARNING: Long and ardorous - difficult to trace behaviour ]
Behaviour described is without EV_PERSIST on internal signal handler (as it's
been for months):
1. signal comes in, we jump to our internal signal handler, it writes to pipe.
2. epoll_wait() returns -1/EINTR because a signal handler wa
1. Fix a debugging call with wrong format, (we should probably use
__attr__((format(printf))) eventually).
2. Add additional debugging calls for sanity.
-cl
Index: signal.c
===
--- signal.c(revision 507)
+++ signal.c(working
On Sat, Nov 10, 2007 at 12:18:25AM -0500, Nick Mathewson wrote:
> On Fri, Nov 09, 2007 at 02:27:07AM -0800, Christopher Layne wrote:
> > Regress checks out OK with both -O0 and -Os. Both size are with -O0.
>
> Applied; thanks!
Unfortunately I'm noticing that it's cau
Separate build dir issue.
Index: sample/Makefile.am
===
--- sample/Makefile.am (revision 506)
+++ sample/Makefile.am (working copy)
@@ -1,7 +1,7 @@
AUTOMAKE_OPTIONS = foreign no-dependencies
LDADD = ../libevent.la
-AM_CFLAGS = -I
On Fri, Nov 09, 2007 at 06:23:33PM -0500, Nick Mathewson wrote:
> On Fri, Nov 09, 2007 at 06:27:04AM -0800, Christopher Layne wrote:
> > [ Warning: this is long and detailed, but includes details of a present
> > bug in libevent. ]
>
>
> Hi, Christopher! This all see
On Fri, Nov 09, 2007 at 04:38:43PM -0800, Scott Lamb wrote:
> >Fix in same, or sweep up in a later patch? How many other places are
> >there where we're not currently checking the return value of
> >event_add()? If there are more than this, we might as well just do it
> >separately.
> >
> >-cl
>
>
On Fri, Nov 09, 2007 at 04:03:46PM -0800, Scott Lamb wrote:
> Christopher Layne wrote:
> >+/* save previous handler setup */
> >+if (sigaction(evsignal, NULL, sig->sa_old[evsignal]) == -1
> >+|| sigaction(evsignal, &sa, NULL) == -1)
>
> Not wo
[ Warning: this is long and detailed, but includes details of a present
bug in libevent. ]
While building libevent with -W -Wall -pedantic, I came across this:
signal.c: In function 'evsignal_del':
signal.c:162: warning: ISO C forbids conversion of function pointer to object
pointer type
Which
Regress checks out OK with both -O0 and -Os. Both size are with -O0.
$ size .libs/libevent-1.4.so.2
textdata bss dec hex filename
9373510887084 101907 18e13 .libs/libevent-1.4.so.2
$ size .libs/libevent-1.4.so.2
textdata bss dec hex filename
93
On Thu, Nov 08, 2007 at 08:11:55AM -0800, Garth Patil wrote:
> http://sfbay.craigslist.org/pen/cpg/472325599.html
>
> libevent programmer wanted (san mateo)
> - NOT BLOCK ON ANY STEP
close() can block. *boom tsst*.
-cl
___
Libevent-users mailing list
L
On Tue, Nov 06, 2007 at 02:05:30AM -0500, Nick Mathewson wrote:
> Update: I have added 2 patches, 10 feature requests, and 12 bug
> reports to the tracker. I re-read or skimmed about 500 emails to do
> this, so it is likely I missed something, or added a bug that has
> already been fixed. My apol
On Sun, Nov 04, 2007 at 09:37:52PM -0800, Scott Lamb wrote:
> For this program, it's important to know more than that an error has
> occurred. EV_ERROR is totally inadequate. You're using it for several
> different cases. I spotted at least these three:
>
> * malloc() failed in ev_once - transient
On Sun, Nov 04, 2007 at 04:23:01PM -0800, Scott Lamb wrote:
> > It wasn't what I expected; I was fully confident at first that the
> > thread-pool, work-queue model would be the way to go, since it's one
> > I've implemented in many applications in the past. But the numbers said
> > otherwise.
>
>
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
> > he
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 li
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 terms of concrete data types, you appear to have used a binary heap?
> So b
On Sun, Nov 04, 2007 at 12:15:56PM -0800, Steven Grimm wrote:
> On Nov 4, 2007, at 8:13 AM, Marc Lehmann wrote:
> >This would create additional loops (event_bases). The difference is
> >that
> >these cannot handle signals (or child watchers) at all, with the
> >default loop
> >being the only on
On Sat, Nov 03, 2007 at 05:53:42PM -0700, Niels Provos wrote:
> Well, Rob Pike has many great insights. He also does not like
> conditional compilation. However, you are right, evhttp.h could
> resolve the dependency on queue.h internally. I will look into it.
Agreed, Rob Pike is true blue - an
On Sat, Nov 03, 2007 at 04:56:07PM -0700, Niels Provos wrote:
> Try
>
> #include
>
> before including evhttp.h
>
> Niels.
Why is this a usercode issue? Shouldn't evhttp.h be more interested in
handling it's dependencies than non-event parent code? It's similar to the
being a usercode, but eve
On Thu, Sep 27, 2007 at 08:31:32AM -0700, Niels Provos wrote:
> Hi Christopher,
>
> I am not sure if this is necessarily the right way to go for a
> library, esp if it can impact backwards compatibility for
> bufferevents. As for reducing the size of the library, do you really
> think that 30K ma
$ ./configure --help
[...]
Optional Features:
[...]
--enable-dnsbuild with support for dns layer [default=yes]
--enable-http build with support for http layer [default=yes]
--enable-beventsbuild with support for buffer events [default=yes]
Changes:
1. This requ
It's really difficult to have a diff explain manpage changes due to
the nature of ROFF markup, etc.
Positional changes:
Moved the opening paragraphs about signal specific issues to right
under the signal_add(), signal_set() section, since they're related.
Moved the opening paragraphs about event_
On Thu, Sep 20, 2007 at 01:52:31PM +0200, Trond Norbye wrote:
> The result of gettime is not used if the timetree is empty (and might
> cause a context switch to get the system clock).
>
> --Trond
> Index: event.c
> ===
> --- event.
On Tue, Sep 18, 2007 at 10:10:42PM -0500, M.H.VanLeeuwen wrote:
> Hi,
>
> When event_add(&ev, &tv) returns -1, what is the proper way to clean up.
>
> For example function XYZZY() takes socket fd as an argument
>
> XYZZY(int sockfd)
> {
> allocate event structure related memory...
> ...
>
1. event_rpcgen.py will fail to open regress.rpc if building outside the source
directory.
-cl
--
Index: Makefile.am
===
--- Makefile.am (revision 433)
+++ Makefile.am (working copy)
@@ -18,7 +18,7 @@
bench_SOURCES = bench.c
reg
1. Change output to provide a single line pct done + avg/min/max.
2. Add "-l" flag to support previous style.
3. Add "-x n" flag to specify max loop iterations.
In a nutshell, output looks like this:
$ debug/test/bench -x 8192
done avg min max
17% 942
Compilation errors in http.c and a segfault during "make verify" when
USE_DEBUG is defined.
Index: libevent/http.c
===
--- libevent/http.c (revision 429)
+++ libevent/http.c (working copy)
@@ -1174,7 +1174,7 @@
if (str
On Sat, Aug 04, 2007 at 07:21:46PM -0700, Scott Lamb wrote:
> Christopher Layne wrote:
> >On Thu, Jul 19, 2007 at 01:14:58PM -0700, Scott Lamb wrote:
> >>When I use "valgrind --tool=memcheck" on a libevent-based program, it
> >>gives the following complaint:
&
On Thu, Jul 19, 2007 at 01:14:58PM -0700, Scott Lamb wrote:
> When I use "valgrind --tool=memcheck" on a libevent-based program, it
> gives the following complaint:
>
> ==15442== Conditional jump or move depends on uninitialised value(s)
> ==15442==at 0x4C0F2D3: event_add (event.c:632)
> ==154
recv timeout, event == 1, 3, 0
^ From my own code, just debugging data, but pertinent in that it was just a
timeout
event which was received. Since it seems one cannot have a persistent time out
event
with a relative timeout (mentioned previously) - I always delete and re-add the
specific
receiv
On Tue, May 08, 2007 at 06:38:51PM -0700, William Ahern wrote:
> > received a non-timeout event. In a way this is absolute, not in the epoch
> > sense, but that it's tied to the time event_add() was called and not
> > relative
> > to when the last valid event was received.
>
> That may or may not
On Tue, May 08, 2007 at 02:03:17PM -0700, Niels Provos wrote:
> On 5/8/07, Phil Oleson <[EMAIL PROTECTED]> wrote:
> >So.. To fix your implementation you will need to do something like I did.
> >I reimplemented libevents' gettime() function (because it's not exposed
> >via event.h) and use it inste
I understand that EV_PERSIST basically means that one does not have to
continually reschedule the event upon the event occuring.
Consider the following simple test case and my following question on it...
#include
#include
#include
#include
#include
#include
int pfd[2];
int persist[2];
stru
43 matches
Mail list logo
