ev_prepare watcher awkwardness

Marc Lehmann schmorp at schmorp.de
Tue Apr 21 02:54:27 CEST 2015


On Tue, Apr 21, 2015 at 02:19:40AM +0200, Thilo Schulz <thilo at tjps.eu> wrote:
> Or is it that some of us in this day and age of information overload lose 
> sight of the little details?

It's entirely normal to lose sight of the little details, that's not the
issue - ask, and you will receive a pointer, as long as you made a reaosnable
effort yourself thats fine.

The problem here was that you indeed voiced all sorts of misconceptions
and wanted to change libev - to help you, one first needs to cut through
all that to find out what your problem is, and that takes time and effort.

> 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.

That's one way to do it, the other is to look at what ev_run does. It is a
rather advanced function, too, though.

> 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 
> :)

Well, it takes unnecessary time and effort to first have to shoot down
your misconceptions. It is simpler if you simply stated your problem and
your attempt at solving it.

> 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.

I don't think libev makes it very hard to use it's API correctly - you didn't
have an issue using ev_prepare_start to start your watcher, it just didn't do
what you wanted it to do.

> > 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.

Keep in mind that ev_prepare watchers are invoked in every event loop
iteration. When you start it after the "before the poll call" moment
passed, it would still be called before the next poll.

> > 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.

Sure, unfortunately, too much information is also confusing, and especially
with watcher docs we are quite near that limit.

For rather uncommon usecases, a bit more effort and even reading the sources
to understand some of the finer details is hopefully in the bets interest for
the majority of users.

> > (It also works with ev_prepare watchers).
> 
> Or the generic ev_watcher watcher for that matter, I presume.

I guess it would, if libev had something like generic ev_watchers, but
it hasn't (at least not officially). The struct ev_watcher you see is
effectively the base class for watchers, it is not a watcher itself,
although tricking the code to treat it like one would work in current
versions, owing to the fact that a watcher really is just a few ints and a
callback.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list