EV incompatibility WAS Re: Mojo implementation?

[Felipe Gasper]

> On Oct 25, 2020, at 1:11 AM, Marc Lehmann <schmorp at schmorp.de> wrote:
> 
> On Sat, Oct 24, 2020 at 07:40:00PM -0400, Felipe Gasper <felipe at felipegasper.com> wrote:
> 
>> We don’t use EV, and when we’ve tried it some of our tests have broken. That may indicate bugs on our end that should fix,
> 
> That is highly likely, and would, in my eyes, be a very worthwhile thing
> to investigate, as the chance that it indicates bugs in Mojo is high. A
> good first step would be to run with PERL_ANYEVENT_STRICT=1 in the
> environment, which would catch many simple bugs (but of course can't do
> miracles).

I dug a bit. You’re half-right.

It’s an incompatibility between our code and libev. Instead of using a child watcher we create a pipe and give the write end of it to the subprocess. Then we install a read watcher in the parent process; once the pipe is readable, the child is ready to be reaped. It’s kind of a “poor man’s pidfd” that avoids clobbering global $SIG{CHLD}.

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.

Our approach is unconventional but, 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.

Should AE’s docs specifically forbid what we’re doing? 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. Based on AE’s behavior, though, it looks like AE should be the only thing that reaps?

-FG