Using EV_CUSTOM for custom events

[Konstantin Osipov]

Hello,

Thank you very much for your reply.

* Zsbán Ambrus <ambrus at math.bme.hu> [12/04/27 22:49]:


> On 4/27/12, Konstantin Osipov <kostja.osipov at gmail.com> wrote:
> > I'm looking for an efficient mechanism to asynchronously invoke
> > one callback from another, or awake one watcher from another.
> >
> > Currently we use ev_async for that, but it involves writing
> > into a pipe, and is thus slower than I would like it to be.
> There are two cases.
> (A) If you possibly want to signal an event from one thread to another
> (or from a signal handler etc), then you must use an ev_async watcher
> and signal it with ev_async_send.  This copes with the fact that the
> event loop might not be in a consistent state.  The ev_async_send
> function may actually need to write to a pipe (or some similar quick
> system call) because otherwise it couldn't wake up the event loop if
> it's currently sleeping or close to sleeping.  If, however, the event
> loop is not currently sleeping, then ev_async_send avoids the system
> call most of the time, provided that you're using a recent enough
> version of libev.

Could you please confirm that I understood your explanation
correctly:
When event loop is not blocked (sleeping) ev_async_send() does not
have to write to a pipe, even if executed from a different thread.
In that case, what does it use, some sort of atomic?

> (B) If you want to signal only from a clear state, such as from a
> watcher callback in the same thread, or when the event loop is not
> running, then you don't need ev_async. In this case, you can use the
> ev_feed_event function, and it doesn't really matter what kind of
> watcher (eg. ev_signal) and what event (such as EV_CUSTOM) you're
> using. The caveat is that multiple events fed to the same watcher can
> be collapsed to a single event.  Alternately, you could create a new
> watcher, possibly a timer with zero timeout.

OK, a timer with zero timeout looks safer than a watcher on a
signal, since in the latter case there could be spurious wake-ups.

On the other hand, if libev avoids the costly write to a pipe
when the loop is not blocked, my intent to optimize this part
seems to be unsubstantiated.

Thank you,

-- 
http://tarantool.org - an efficient, extensible in-memory data store