On Thu, Jan 24, 2013 at 02:17:49PM +0400, Konstantin Osipov
<kos...@tarantool.org> wrote:
> > > Forking libeio is and (has always been with free software)
> > > an obvious option.
>
> For these we need a reliable thread-pool of "gophers", i.e.
> performers of random tasks, and libeio eio_custom fits here pretty
> well.
Using the internal threadpool of an async I/O library while not doing any
I/O with it is indeed a design bug.
> There is a win for us since there is no other library out there
> which can do async getaddrinfo() and integrate well into libev
Well, libeio can't do that either at the moment - you'd have to modify it,
while making sure to not use it for I/O. That requires that you do not use
third party libraries that might also use libeio, for I/O possibly.
When you modify code, you cna use just about any threadpool out there. While
I wouldn't recommedn the glib threadpool, I can't see why it wouldn't
integrate nicely inot libev either,
What makes libeio integrate nicely is the fatct hat libev has support for
this kind if integration. If you look even more closely, you will even see
that libeio isn't actually a perfect match for ev_async's.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
