ev_prepare watcher awkwardness

Thilo Schulz thilo at tjps.eu
Tue Apr 21 02:19:40 CEST 2015


Sorry, again forgot to send this to the list:

Hey Marc,

On Monday 20 April 2015 17:25:54 you wrote:
> First of all, there are no limitations on adding prepare watchers from
> other prepare watchers. What you talked about is the semantics of doing
> that, and this is described in detail in the ev_run documentation.

Yes, okay. Even after you pointed the ev_run section out to me, it took me 
about three looks until I noticed "Queue and call all prepare watchers". 
*Sigh*. Are my reading skills that bad?
Or is it that some of us in this day and age of information overload lose 
sight of the little details?

> Because there is nothing special about it - adding an I/O watcher or a
> timer will also not magically invoke it before the next poll, only when
> their respective event occured.

Right, I kind of thought this to be obvious that's why I didn't spell this 
out..

> And if you need to know more, you can read the source code.
> 
> None of that is required to solve your problem, so this is all academic.

From reading the doc, I never really understood how ev_feed_event worked. It 
was actually only when I read the source code that more clarity came about. It 
actually does what I need, my suggested "new" watcher "Execute immediately 
after return from this watcher callback". So I am quite happy now.

> You mention this as if it would somehow be a problem, or unexpected. To
> *really* understand libev, reading its source code might well be required.
> 
> The important point to take home is that, even though you might understand
> how libev does it, that doesn't mean you can rely on the undocumented
> bits.
> 
> Yes, there might be this internal function that might seem to do exactly
> what you want, and you can clal it, but it might not even exist in a
> future version.

Point taken.

> However, when you try to speak authoritatively about libevs behaviour and
> what works and what doesn't, you need to spent a lot more effort than if
> you just want to ask a clarifying question.

True that, but I never claimed to speak authoritatively. I am putting my 
thoughts out there, and wait eagerly for you to shoot down my misconceptions 
:)

> Which is not a problem, since people who use the documented API in the
> described way will not need this deep understanding.

Well, kind of a chicken-or-egg problem: to know whether I'm using the API in a 
documented way, I need to understand the docs first, and that correctly.

> So, while we can move from the user-level to the implementation level and
> happily discuss implementation strategies or rationale, you (and other
> people reading this) should be aware that these are internals that are
> free to study and free to exploit, but if stuff breaks, it's all your
> problem.

Point taken.

> What doesn't work is when you try to use ev_prepare for a completely
> different usage, for which it isn't designed and for which it wouldn't
> work anyway, because even *if* you start another ev_prepare watcher inside
> an ev_prepare watcher callback it *will* be called before the process
> blocks.

I'm a bit confounded by this paragreph. Yes, my use probably was not what 
prepare watchers are designed for. But the last part of that sentence rings 
false to me.
After the pending fork watchers have been executed, the prepare watchers will 
be queued, and then executed.
I'm quite sure about that when you do 
  ev_prepare_start(loop, prepwatcher2);
inside such a prepare watcher callback, it will definitely _not_ start 
prepwatcher2 before the process polls for fd events (which may or may not 
block), because ev_prepare_start will not queue the watcher. This will only 
happen at the next event loop iteration.

> And in this case, the libev documentation is rather detailed, not to
> mention that, as a free software library, you cna go to whatever level of
> detail you need by studying the source code.
> 
> No, nobody can guarantee that you will have a clear understanding
> afterwards.

Of course not. But I'm sure you'll find out after interacting with your users 
if and where there may be room for improvement.

> If you use an idle watcher and feed it a custom event, as has been
> mentioned multiple times, it would be called long before your prepare
> watcher. No need to even start it. And if it has higher priority than
> the currently executed watcher, it will even be the very next callback
> invocation, a mere dozen cycles or so later.
> 
> (It also works with ev_prepare watchers).

Or the generic ev_watcher watcher for that matter, I presume.

> > Right, ev_feed_event(). I assume it will work if I use feed event on any
> > watcher with the same priority as the watcher being currently executed.
> > Correct?
> 
> It will work on any valid watcher, whether started or not, regardless
> of priority. Priority only orders watchers, it doesn't stop them from
> working (see the documentation of ev_priority).
> 
> These events will be executed during the current or next ev_invoke_pending
> call, so typically really soon, and typically long before eny ev_prepare
> watchers.

Great! It is indeed what I need.

-- 
Best regards,
Thilo Schulz



More information about the libev mailing list