libev/libuv interoperation with ev_async
mons at cpan.org
Mon Nov 30 20:47:24 CET 2020
Thank you for the reply
On Mon, Nov 30, 2020 at 9:41 PM Marc Lehmann <schmorp at schmorp.de> wrote:
> On Mon, Nov 30, 2020 at 09:29:48PM +0300, Mons Anderson <mons at cpan.org> wrote:
> > I've found that all I need to integrate them is to have access to
> > evpipe (to put a watcher on it from another event loop), but libev
> > interface doesn't provide any way to access it.
> What exactly do you mean with evpipe? The internal evpipe member?
Yes, I meant loop->evpipe
> The problem is that it is not clear what you want to (or can) do with it
> - its value and use is essentialy undocumented, undefined, and can change
> at any time. I'd be hard presed to see what potential use its value could
> be. Specifically, evpipe can NOT reliably tell you when an ev_async_send
> is pending.
I'll try to make it more verbose and I'll provide links to code, if it
would be easier to read code
We have an app (github.com/tarantool/tarantool), which uses libev and libcoro.
All the work with database structures are performed from so called tx-thread
Every thread works in cooperative multitasking mode
For networking with clients created a separate, net thread
Communication between threads works using cbus and cpipe
which in fact are wrappers on top of ev_async
For now we want to create module interface, that will allow to create network
modules, that behave like our native network module but without strict
dependency on ev in that worker/network thread
For now, as a module interface we have <ev.h> and ours <tarantool/module.h>
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
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 ;)
> Note that libev does not protect its internal members, so you could embed
> libev in a version where you understand and/or can guarantee that the evpipe
> member works as you want it to, e.g. in my_ev.c:
> #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)
<inthrax at gmail.com>, <mons at cpan.org>
More information about the libev