Bug Report: SIGPIPE during call to ev_async_send

Benjamin Mahler benjamin.mahler at gmail.com
Mon Oct 12 01:42:03 CEST 2015

Interesting, from what I can tell we don't trip the postfork=1 code in the
link below within our hot paths, but we do trigger it reliably in some of
our unit tests that use pipes with libev:


We had tried to avoid ignoring SIGPIPE because we use libev in an
asynchronous / actor library that we maintain independently from Mesos
called libprocess. The idea was that libprocess would remain agnostic about
whether SIGPIPE should be disabled (user of the library can decide), and of
course libprocess should not incur a SIGPIPE from its own code (e.g.
disable SIGPIPE for sockets, disable SIGPIPE when writing to a pipe fd,
etc). In retrospect perhaps this was a fool's errand.. :)

So in theory shell filters could be built atop libprocess, but it seems
reasonable to ask users of the library to handle EPIPE in 2015.

I'm curious, do you know when this would make its way into a release? No
worries if not.


On Sun, Oct 11, 2015 at 8:48 AM, Marc Lehmann <schmorp at schmorp.de> wrote:

> On Fri, Oct 09, 2015 at 11:55:17AM -0700, Benjamin Mahler <
> benjamin.mahler at gmail.com> wrote:
> > The bug is rare (on the order of 10 occurrences per day on production
> I've checked in a potential fix for this problem, without testing it. It
> works by avoiding recreation of the signal. It should (reliably) take care
> of your specific problem.
> However, we thought long and hard and didn't find a general solution to
> this problem (it's possible to solve in userspace, but we likely would
> trigger a race condition in the kernel), so we also had to put additional
> limitations on forking and reusing loops in general - basically,
> ignoring SIGPIPE is now a hard requirement if you want to reuse loops in
> the
> child.
> Depending on your application, this is probably trivial to satisfy becaue
> you
> don't reuse loops in the child.
> --
>                 The choice of a       Deliantra, the free code+content
>       -----==-     _GNU_              http://www.deliantra.net
>       ----==-- _       generation
>       ---==---(_)__  __ ____  __      Marc Lehmann
>       --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>       -=====/_/_//_/\_,_/ /_/\_\
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20151011/736f7af5/attachment.html>

More information about the libev mailing list