Re: libev/libuv interoperation with ev_async
On Mon, Nov 30, 2020 at 10:47:24PM +0300, Mons Anderson 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
Re: libev/libuv interoperation with ev_async
On Mon, Nov 30, 2020 at 09:29:48PM +0300, Mons Anderson 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? 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. 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. -- 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
libev/libuv interoperation with ev_async
Hello I have an app that is built on top of libev. It has worker threads that communicate with the main thread using ev_async. For now I need to integrate a library that is built on top of libuv (for ex: h2o). 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. Could you please help me to find the correct way of such an integration? Or maybe extend ev.h with something like ev_pipe_fds(loop, ) -- Best wishes, Mons Anderson , http://github.com/Mons ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
Re: Iteration over registered handlers
On Wed, Nov 25, 2020 at 02:43:21PM +0100, Rick van Rein wrote: > I love libev. The complex to-do list in my mind quickly clears up when > I add it to a project. It's lovely to have this global database under a > single pointer that pops out relevant data alongside interesting events. > > For cleanup purposes, I'd like to iterate over registered event handlers > after I've broken out of a loop. I cannot find a macro or function, is > that not part of the API? It's not part of the API because it would require libev to add overhead to track watchers. If you need this functionality, you can add it easily on top of libev. Doing it yourself also ensures that you are only doing it to your own watchers, and not watchers by others (e.g. libev internal ones). Even if you could iterate over all watchers in libev, how would you decide which watchers are your own without outside knowledge? > [I'm cautious about hacking it in, because of the obvious fine balance > of platform knowledge built into the code.] It's probably just as simple and easier to maintain wrappers around the start/stop functions you use. -- 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
