Optimal multithread model

Marc Lehmann schmorp at schmorp.de
Wed Mar 17 12:21:23 CET 2010

On Wed, Mar 17, 2010 at 11:15:11AM +0100, Christophe Meessen <christophe at meessen.net> wrote:
> This libcoro library is very interesting. Is libcoro used in libev ?

Oh my, beware, of course not :)

But libev is of course designed with coroutines (which I use to mean
cooperative threads) in mind as well, which is why all the thread trickery
such as running ev_loop in multiple threads on the same loop works as long
as you use locking.

Maybe you also find libeio interesting, it works well
but has no documentation (IO::AIO docs might help):

> I'll also have a look at state-thread  
> [http://state-threads.sourceforge.net/].

libcoro is more a nucleus that *could* be used in stuff like libpth, ST
and so on for context switching, it's not aiming to be a thread package.

i.e. it tries to do one thing well: context management. it doesn't even
manage your stack for you.

you'd be advised to go with something like ST unless you really want to
roll your own stuff.

> I'm also very impressed by the feasibility of the callback use you  
> described. This is very powerful. I must reread the document, I missed  

If you find a way to express these things simpler that would be
apptreciated, or if something is not clear. I find it hard to explain what
you can actually do or not, as so much terminology is fuzzy (not everybody
sees "coroutine" as meaning "cooperative thread", and the latter does not
make clear what cooperation actually means).

> that information. I assumed that libev was a simple wrapper around  
> ePoll/kEvent/select.

it tries to be simple, but not dumb.

I originally envisioned libev as more being a little monster - idle watchers
should have one or two timeouts attached to them and so on, with lots of
event queue management.

The result is more like a construction kit for these kind of things, where
you can build your own timeout idle watchers if you so desire (a good
example how to do so is the ev_once implementation, although the malloc
inside is non-canon :)

This is cool to me and many others, but suffers from the same problem as
libcoro: it's more a nucleus, it doesn't have spiffy socket abstractions,
TLS, DNS and HTTP support and so on.

I am not offended if somebody chooses libevent because she needs those
extra features (or glib, or...) - choose wisely.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list