<div dir="ltr">Ah sorry for not testing it earlier, applying this diff didn't fix the issue in our test suite. Looking at the diff more closely, it seems to only address one of the postfork cases in epoll_poll, whereas we seem to be tripping the other case, here:<div><br></div><div><a href="http://cvs.schmorp.de/libev/ev_epoll.c?revision=1.69&view=markup#l206">http://cvs.schmorp.de/libev/ev_epoll.c?revision=1.69&view=markup#l206</a></div><div><br></div><div>I injected print statements to validate that we are indeed hitting that line in our tests.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 12, 2015 at 6:00 AM, Marc Lehmann <span dir="ltr"><<a href="mailto:schmorp@schmorp.de" target="_blank">schmorp@schmorp.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Oct 11, 2015 at 04:42:03PM -0700, Benjamin Mahler <<a href="mailto:benjamin.mahler@gmail.com">benjamin.mahler@gmail.com</a>> wrote:<br>
> Interesting, from what I can tell we don't trip the postfork=1 code in the<br>
> link below within our hot paths,<br>
<br>
</span>That's good from a performance standpoint. since you say it's a rare event in<br>
production code, it makes sense that it isn't triggered in the hot path.<br>
<span class=""><br>
> We had tried to avoid ignoring SIGPIPE because we use libev in an<br>
> asynchronous / actor library that we maintain independently from Mesos<br>
<br>
</span>Well, unless you fork and try to use the loop in the child, that is fine. The<br>
rationale behind making this a requirement on fork, rather than some other<br>
alternative, is that fork has a lot of other process-wide requirements as<br>
well.<br>
<span class=""><br>
> So in theory shell filters could be built atop libprocess, but it seems<br>
> reasonable to ask users of the library to handle EPIPE in 2015.<br>
<br>
</span>shell filters can still be built - as long as you don't fork and do event<br>
processing with the same loop in the child, that should be fine. It's not<br>
really difefrent than using threads, threads put a lot more limitations on<br>
fork, and trying to do multiprocessing in forked processes is generally<br>
asking for trouble, so this is not seen as a particularly bad extra burden-<br>
<br>
Again, you don't have to worry about it if other parts of the program fork,<br>
as long as they don't use your library in the child.<br>
<br>
Alternatively, somebody might come up with a solution, but the problem is<br>
that we can't use lcoks (it has to work from signal handlers), and the other<br>
thread or signal handler can be delayed wihtout any upper bound.<br>
<br>
So while we can replace the write fd atomically (from a userspace<br>
perspective), the linux kernel will still suffer from a race, where one cpu<br>
replaces the fd with another file description, but the other cpu has already<br>
fetched it and locked it, and will then trigger the SIGPIPE. (basically, when<br>
you call write in one thread and close on the same fd in another, the kernel<br>
might suffer form bad effects, for example, the write might block forever).<br>
<br>
The only solution we found is to not let this happen in general, but avoid<br>
this case entirely in important situations, such as when epoll recreates the<br>
poll set - we don't have to rebuild the event pipe in this case, so we don't.<br>
<br>
We do have to rebuild the event pipe, though, in a child process, before<br>
using the associated loop (and only iff using the loop), and then I don't see<br>
a way to avoid a race between a signal handler and the pipe rebuild code (or<br>
a newly started thread).<br>
<span class=""><br>
> I'm curious, do you know when this would make its way into a release? No<br>
> worries if not.<br>
<br>
</span>Hopefully "soon" there will be a release, and it will have that code. I am<br>
mainly waiting for you to test whether the change in libev seems to fix your<br>
problem or not.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
                The choice of a       Deliantra, the free code+content MORPG<br>
      -----==-     _GNU_              <a href="http://www.deliantra.net" rel="noreferrer" target="_blank">http://www.deliantra.net</a><br>
      ----==-- _       generation<br>
      ---==---(_)__  __ ____  __      Marc Lehmann<br>
      --==---/ / _ \/ // /\ \/ /      <a href="mailto:schmorp@schmorp.de">schmorp@schmorp.de</a><br>
      -=====/_/_//_/\_,_/ /_/\_\<br>
</div></div></blockquote></div><br></div>