Vinay, apologies for the long time you took me to respond (the notification
was stuck in my Spam folder, thanks Gmail!). Indeed, both of your comments
are spot on. In my particular case, I ended up implementing what your first
suggestion alludes to (a retry capped by a maximum).

The reason for my reporting this is because the existing (mainlined)
implementation has shortcomings, which might be affecting others out there.

I contacted the module developer, but no response. So assuming we have a
consensus from whomever "owns" the module, I can volunteer to do a proper
patch.

On the issue of maximum retries, I would go with a reasonable
(configurable) max as well as a (configurable) back-off sleep.

On Sun, Feb 7, 2016 at 1:57 PM, Vinay Sajip <report@bugs.python.org> wrote:

>
> Vinay Sajip added the comment:
>
> The problem with your suggested fix is that if you keep getting EAGAIN,
> the handler will appear to hang. If you want to suggest that maybe we limit
> the number of tries, then what number of retries would you pick, and why?
> Also, a caller might want to know about EAGAIN, so I'm not sure you'd want
> to (effectively) swallow it in the handler.
>
> Perhaps a different strategy (than just trying for ever) would be better.
> If you know the application is unusual in having a SIGPIPE handler and you
> think this is a contributory factor, why not just subclass the handler, add
> a more resilient emit() and use that in your application?
>
> ----------
> status: open -> pending
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue25459>
> _______________________________________
>

-- 

Henrique Andrade | +1-530-426-2123 | hcma@unscrambl.com |
http://unscrambl.com