On Mon, Jun 22, 2009 at 11:16:33PM +0200, Marc Lehmann wrote:
> On Mon, Jun 22, 2009 at 04:44:49PM +0200, Gabriel Kerneis
> <[email protected]> wrote:
> > cooperative, (continuation-based) threads. These threads might be
> cool!
You can check:
http://www.pps.jussieu.fr/~jch/software/cpc
for more information, and:
darcs get http://www.pps.jussieu.fr/~kerneis/software/repos/cpc
for the code.
darcs get http://www.pps.jussieu.fr/~kerneis/software/repos/hekate
is a sample program (a BitTorrent seeder) using cpc.
NB: all of this is still at a rather experimental stage, should be
released in a few weeks/months. But cpc works well to compile hekate,
and hekate works well in our benchmarks :-)
> The refcount exists solely to terminate > ev_loop.
This is what I expected, indeed, thanks for confirming it.
> > Does it sound right? Could I get a busy wait when everybody is detached
> > or does the async watcher handle that case nicely?
>
> I don't fully understand this combination - the async watcher itself
> keeps a reference, and yes, it's possible to have just an async watcher
> (which will keep the loop alive), in which case you wouldn't really need
> additional references too.
I just wanted to know if a loop with an async watcher (and nothing else)
will busy wait (using 100% of the CPU) or "sleep" in some way until it
is woken up (using 0% of the CPU).
> Also, if the only reason for the async watcher is ev_unref, you can safely
> call libev functions from any of your cooperative threads (as long as they
> are really cooperative, i.e. ev_loop blocks the process and switching is
> done only inside callbacks).
Yes, they are, and I call libev functions that way, in attached mode
(except for ev_async_send which is called in detached mode too, of
course).
> > [Completely unrelated: I'm a bit concerned that libev includes external
> > headers.
>
> Well, libev cannot work without external functions and datatypes. If you mean
> the header file, I cannot guarantee that you will be able to switch it off
> (inttypes.h is a good candidate).
I mean anything that includes features.h in the glic, since it prevents
my users to use the _GNU_SOURCE macro in a simple way (for tricky
reasons). In the case of ev.h, it's signal.h (for EV_ATOMIC_T) and
sys/stat.h (for the statistics). I'll use int with a big warning, anyway
I'm not portable (more or less requiring gcc).
Thanks for your answers.
Regards,
--
Gabriel Kerneis
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
