Also, the stuff about event compression aside, you'll need some kind of
barrier operations on the queue itself at the very least if you wanted this
to work reliably on all SMP machines under all circumstances (e.g. Marc's
libecb stuff).
On Tue, Mar 18, 2014 at 7:01 AM, Evgeny Zajcev
On Thu, Jan 10, 2013 at 10:05 AM, Bo Lorentsen b...@lue.dk wrote:
The thing is ... this works amazingly, until I try to startup this app as
a daemon (fork). And yes, when i start it as i daemon i make sure to call
ev::post_fork(), and my default loop starts up as it is supposed to (but
later
On Mon, Jun 18, 2012 at 12:43 AM, yao liufeng ylf...@163.com wrote:
can someone help to clarify whether it's a
memory leak or something wrong with the code? Thanks!
Googling around, it seems like in the past year or two there's been
some flareup between C99/C1X, POSIX, and glibc about
On Mon, Jun 18, 2012 at 4:50 PM, Brandon Black blbl...@gmail.com wrote:
However, whether it's a
simple bug or somehow intentional behavior is unclear to me given all
that arguing about malloc(p,0) between glibc/C/POSIX people.
Shortly after the last email, I noticed the realloc() docs
On Mon, Jun 11, 2012 at 4:39 AM, 钱晓明 mailtoanta...@163.com wrote:
If I have started a io_watcher with EV_READ event, but later I want to set
EV_WRITE event in callback function of EV_READ, should I have to call
ev_io_stop first, then ev_io_set and ev_io_start again?
If all messages have been
On Mon, Jun 4, 2012 at 8:40 AM, Marc Lehmann schm...@schmorp.de wrote:
On Mon, Jun 04, 2012 at 02:44:19PM +0200, Joachim Nilsson
troglo...@gmail.com wrote:
On Mon, Jun 4, 2012 at 2:29 PM, Marc Lehmann schm...@schmorp.de wrote:
On Mon, Jun 04, 2012 at 08:41:38AM +0800, 钱晓明
On Thu, May 10, 2012 at 6:28 AM, Vetoshkin Nikita
nikita.vetosh...@gmail.com wrote:
So correct SIGCHLD handler should loop calling waitpid() until no zombies
exist.
Please, correct me, if I'm wrong.
The code does appear to loop on waitpid as you describe, it just
does so by feeding itself new
On Tue, May 8, 2012 at 9:47 AM, Marc Lehmann schm...@schmorp.de wrote:
if (j++ 1)
{
assert ((libev: io watcher list contains a loop, w != w2));
w2 = w2-next;
}
And see if that makes it go away? (I never implemented this particular
algorithm
2012/3/25 Zoltán Lajos Kis zoltan.lajos@gmail.com:
Even if you lock the mutex before the call to ev_ref and ev_run, the outcome
is still the same: the one minute delay remains.
From the docs for ev_set_loop_release_cb:
While event loop modifications are allowed between invocations of
On Sat, Jan 14, 2012 at 1:23 AM, Zaheer Ahmad zaheer@gmail.com wrote:
Whenever you want to start/stop a watcher or do other modifications to
an event loop, so its unclear to me which other api are not thread safe
apart from ev__start/stop. Are ev__init, ev_feed_event,
ev_clear_pending,
On Tue, Jan 3, 2012 at 5:02 AM, Yaroslav yaro...@gmail.com wrote:
Interesting observation: removing __thread storage class makes thread data
shared by all threads. Even without any locks concurrent modifications of
the same memory area result in 5-10 fold test time increase. I.e., shared
On Mon, Jan 2, 2012 at 4:49 PM, Colin McCabe cmcc...@alumni.cmu.edu wrote:
The problem is that there's no way for the programmer to distinguish
the data that really needs to be shared from the data that shouldn't
be shared between threads. Even in C/C++, all you can do is insert
padding and
On Sat, Dec 31, 2011 at 2:36 PM, Jorge jo...@jorgechamorro.com wrote:
tThreads(seconds): 0.535, tProcs(seconds): 0.573, ratio:0.933
Perhaps I'm doing it wrong ?
Could you run it on other unixes and post the results ?
I used -O3 -pthread for CFLAGS and got the following results on two
vastly
On Thu, Dec 22, 2011 at 1:05 AM, Hongli Lai hon...@phusion.nl wrote:
2. Suppose the system has two cores and N = 4, so two processes or two
threads will be scheduled on a single core. A context switch to
another thread on the same core should be cheaper because 1) the MMU
register does not
On Thu, Dec 22, 2011 at 7:53 AM, Hongli Lai hon...@phusion.nl wrote:
I know that, but as you can read from my very first email I was planning
on running I threads, with I=number of cores, where each thread has 1 event
loop. My question now has got nothing to do with the threads vs events
On Thu, Dec 8, 2011 at 4:18 PM, Hongli Lai hon...@phusion.nl wrote:
I don't know whether it's fully implemented, but everything that ecb.h
uses *is* fully implemented in llvm-gcc 4.2.1. This is pretty huge
because Xcode 4 now uses llvm-gcc as the default gcc so all OS X users
will get these
On Wed, Nov 2, 2011 at 6:58 AM, Christian Parpart tra...@gentoo.org wrote:
I do think a little bit different here. Think of a server app. The app:
1.) first reads config file,
2.) populates internal data structures out of it,
3.) cleans up its environment (including closing inherited fds,
On Fri, Oct 14, 2011 at 12:48 AM, Shaun Lindsay srlind...@gmail.com wrote:
The problem isn't the volume of timer events. Condensing all the timeouts
to one actual event won't help since, as shown in the example, a single
timeout is vulnerable to early expiration. Basing all your timeouts off
On Tue, Jun 21, 2011 at 1:31 PM, Zabrane zabra...@gmail.com wrote:
Hi Brandon,
Could your proxy code be shared for new comers (as me)?
It'll be very good if build up a repository of libev examples.
Unfortunately it's not very good example code in its current state.
It uses unportable things
2011/6/20 Jaime Fernández jjja...@gmail.com:
b) What's the most convenient way to write data in a TCP socket:
1.- send data directly in the read callback
2.- Create a write watcher
3.- Create a watcher of both types: READWRITE.
It really depends on the nature of the protocol and
On Thu, Jun 2, 2011 at 9:08 PM, Juan Pablo L jpablolorenze...@gmail.com wrote:
thanks for your reply, actually yes i have read the part about the Be smart
about timer,
but this is the first time i have to manage so many timers, and something is
not clear to me.
#4 refers to making a linked
On Thu, Jun 2, 2011 at 10:15 PM, Juan Pablo L
jpablolorenze...@gmail.com wrote:
i m trying to avoid using start/stop or even ev_timer_again because the
socket is considered busy when taken by a thread and thread will hold the
socket for as long as clients have something to send which could be a
On Mon, Apr 18, 2011 at 3:16 PM, Richard Kojedzinszky kri...@cflinux.hu wrote:
So for now, do you say that the whole c++ support is undocumented, and
unsupported?
I think he means only the interfaces documented in the pod are
documented and supported at this time:
On Tue, Mar 29, 2011 at 11:30 PM, Arlen Cuss cel...@sairyx.org wrote:
My question now: say both the ev_timer and ev_io get triggered at the
same time. If the ev_timer callback gets called first, then the ev_io is
stopped and deallocated (as is all the auxiliary data that the ev_io
callback
On Wed, Mar 9, 2011 at 3:23 AM, Marc Lehmann schm...@schmorp.de wrote:
I wonder how much the slowdown of very frequent ev_verify's is compared
to running under valgrind (which presumably would have pinpointed this
problem nicely).
I tried both with this application. Valgrind is considerably
On Tue, Dec 21, 2010 at 2:17 PM, AJ ONeal coola...@gmail.com wrote:
I have a function to process data on a DSP which blocks
and a network socket which gives data to process.
Not knowing the rest of the details, my first stab would probably be
to continue with your model of having a separate
On Sat, Mar 27, 2010 at 3:38 PM, Marc Lehmann schm...@schmorp.de wrote:
On Sat, Mar 27, 2010 at 07:21:52PM +, Chris Dew cms...@googlemail.com
wrote:
// Lots of globals, what's the best way to get rid of these?
put them into a struct, maybe together with the watcher(s), and put it's
On Tue, Mar 16, 2010 at 12:15 AM, James Mansion
ja...@mansionfamily.plus.com wrote:
Brandon Black wrote:
However, the thread model as typically used scales poorly across
multiple CPUs as compared to distinct processes, especially as one
scales up from simple SMP to the ccNUMA style we're
On Tue, Mar 16, 2010 at 9:51 AM, Christophe Meessen
christo...@meessen.net wrote:
Brandon Black a écrit :
The thing we all seem to agree on is that eventloops
beat threads within one process, but the thing we disagree on is
whether it's better to have the top-level processes be processes
On Mon, Mar 15, 2010 at 5:07 PM, James Mansion
ja...@mansionfamily.plus.com wrote:
Marc Lehmann wrote:
Keep in mind thatthe primary use for threads is improve context switching
times in single processor situations - event loops are usually far faster
at
context switches.
No, I don't
On Sat, Feb 20, 2010 at 9:41 AM, Brandon Black blbl...@gmail.com wrote:
I've seen this strict-aliasing issues with libev + gcc 4.4 as well. I
haven't bothered to report it yet simply because I haven't had the
time to sort out exactly what's going on, and whether it's a real
issue that needs
Alejandro Mery wrote:
Hello,
I have an ev_signal watcher upon SIGTERM|SIGINT, but I just noticed ^C
is not been catched by this watcher, only SIGTERM... are multiple
signals on the same watcher supported by libev?
You need to add one watcher per signal, but they can have the same
callback
Brandon Black wrote:
Marc Lehmann wrote:
I just committed code to use a 4-heap instead of a 2-heap to libev.
[...]
I've just tried it against my code, looks pretty good from here. My
test suite passes with the new code, so no breakage.
I spoke too soon (I guess my test suite still needs
On line 369 of ev.h in the latest CVS, EV_ASYNC_ENABLE is typo'd as
EV_ASYND_ENABLE.
-- Brandon
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Marc Lehmann wrote:
http://lists.freedesktop.org/archives/dbus/2006-September/005724.html
In case anyone wonders, quoting from gnu/linux manpages is a very bad
idea, they are often very wrong and in contradiciton to both reality and
the unix specification.
The unix specification says:
In
35 matches
Mail list logo
