On Mon, Nov 30, 2020 at 10:47:24PM +0300, Mons Anderson <m...@cpan.org> wrote:
>
> Every thread works in cooperative multitasking mode
> (https://github.com/tarantool/tarantool/blob/master/src/lib/core/fiber.h#L636)
> For networking with clients created a separate, net thread
> (https://github.com/tarantool/tarantool/blob/master/src/box/iproto.cc#L2055)
> Communication between threads works using cbus and cpipe
> (https://github.com/tarantool/tarantool/blob/master/src/lib/core/cbus.h#L113)
> which in fact are wrappers on top of ev_async
Quite interesting!
> With current state one could create a module using ev backend, since ev_async
> is fully supported by libev. But if worker thread must run another event loop
> there is no good option for how to run, for ex pure select or libuv on top of
> running libev loop
It's still not quite clear to me what you are trying to achieve - so you have
a worker thread that uses libuv, and you somehow want to integrate this into
your main libev loop.
How does the communication work though? Do you want to wake up an uv loop
that the worker is blocking in, or the main ev loop from a uv thread? Or,
likely, something else?
Do you want to write to the evpipe, or read from it? The equivalent of
writing to it can already be done by using ev_async_send. Reading from it
makes no sense, as whether the pipe has something to read or not depends
on the state of libev, it does not signify pending asyncs.
> I know, there are a lot of options for mutual integrations of event loops with
> AnyEvent, EV and other event loops in the world of Perl. I hope to find
> something like that for libev in the C world ;)
Not really, AnyEvent just solves the problem of your loop-agnostic code
running with any event loop, i.e. it allows you to write e.g. perl libraries
that do not depend on a specific event loop.
While AnyEvent+Coro can be used for a lot of tricks in running multiple
event loops, they don't do this by themselves, and there is no generic
recipe to do so.
> > #include "ev.c"
> >
> > ... code can now read evpipe, so you can define a function here.
> >
> > But for this to work reliably you probably have to patch libev anyway, to
> > make evpipe signal async sends reliably.
>
> We'll try to test such an approach. (In my small test snippet it seems to
> work)
I assume you mean accessing evpipe - but accessing evpipe is only one
part, you have to find out what semantics you want from evpipe, and likely
patch libev to provide these semantics, for example, making sure libev
actually allocates a pipe and write for every ev_async_send, neither of
which libev does at the moment.
--
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/mailman/listinfo/libev
