EV incompatibility WAS Re: Mojo implementation?

[Marc Lehmann]

On Sun, Oct 25, 2020 at 01:17:06PM -0400, Felipe Gasper <felipe at felipegasper.com> wrote:
> I dug a bit. You’re half-right.

Hmm, after reading your description, this clearly seems to be a bug in
Mojo, no?

> libev’s default SIGCHLD handler frustrates that by reaping all child processes indiscriminately. So if libev’s SIGCHLD handler precedes our pipe listener, then our listener’s reap of the child process fails with ECHILD.

Libev's SIGCHLD watcher will not interfere with your pipe.

> Our approach is unconventional but,

Don't worry, it's pretty standard, as far as I am concerned. And fully
supported by libev and AnyEvent.

> as far as we can tell, isn’t *wrong* as long as the child process doesn’t itself fork or do anything with that pipe. It works with the pure-Perl loop because, while AE itself also implements that behavior, it doesn’t start doing it until child() is called. Admittedly, this requires that nothing *else* create an AE child() watcher, either.

Well, if you want to hardcode EV as a backend, as it seems you do, then
you can override the SIGCHLD watcher and feed libev any child events. But
if you want to use AnyEvent, you have to play by the rules of any random
event loop backend.

> Should AE’s docs specifically forbid what we’re doing?

No, I don't think so. I am not a friend of forbidding everything, especially as it is
permissible to do your own SIGCHLD handling with some backends (such as EV),
but of course if you go against and explicit "should" in the documentaton
then you are at your own. A "should" is not to be ignored lightly, but is
really a "must" unless you fully understand the consequences. RFCs define
their "should" like this:

SHOULD   This word, or the adjective "RECOMMENDED", mean that there may
         exist valid reasons in particular circumstances to ignore a
         particular item, but the full implications must be understood and
         carefully weighed before choosing a different course.

That's why AnyEvent doesn't prohibit this, but clearly tells you to not do
it.

> Right now it says, “nothing else should use SIGCHLD or reap random child processes”, which implies that, while waitpid(-1) is a no-no, our behavior of reaping a specific (i.e., non-“random”) child process should work.

So while AnyEvent does not expressly forbid it, if you go against it, you
need to deal with the issues you might cause.

Also, you should not confuse AnyEvent with EV here - both can install a
SIGCHLD watcher, and both will reap all children, but you can replace the
EV SIGCHLD watcher, while you cannot replace the AnyEvent SIGCHLD watcher,
mostly because AnyEvent might not even have one (it's an interface to
other event loops, and those loops dictate semantics).

Surely, things could be simpler if the world only had a single event loop,
but the best you can get is the greatest common denominator. AnyEvent's
problem is that I have to take current and future event loops into account,
and the API chosen is what you get.

So if Mojo ever wants to be event-loop agnostic, it would have to play by
the common rules.

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