[Python-Dev] Help preventing SIGPIPE/SIG_DFL anti-pattern.

[Alfred Perlstein]

Hello,

I'm looking for someone in the python community to help with a problem 
of anti-patterns showing up dealing with SIGPIPE.

Specifically I've noticed an anti-pattern developing where folks will 
try to suppress broken pipe errors written to stdout by setting 
SIGPIPE's disposition to SIG_DFL.  This is actually very common, and 
also rather broken due to the fact that for all but the most simple text 
filters this opens up a problem where the process can exit unexpectedly 
due to SIGPIPE being generated from a remote connection the program makes.

I have attached a test program which shows the problem.

to use this program it takes several args.

# 1. Illustrate the 'ugly output to stderr' that folks want to avoid:

% python3 t0.py nocatch | head -1


# 2. Illustrate the anti-pattern, the program exits on about line 47 
which most folks to not understand

% python3 t0.py dfl | head -1

# 3. Show a better solution where we catch the pipe error and cleanup to 
avoid the message:

% python3 t0.py | head -1


I did a recent audit of a few code bases and saw this pattern pop often 
often enough that I am asking if there's a way we can discourage the use 
of "signal(SIGPIPE, SIG_DFL)" unless the user really understands what 
they are doing.

I do have a pull req here: https://github.com/python/cpython/pull/6773 
where I am trying to document this on the signal page, but I can't sort 
out how to land this doc change.

thank you,

-Alfred

-------------- next part --------------
A non-text attachment was scrubbed...
Name: t0.py
Type: text/x-python-script
Size: 2223 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180630/060d0be4/attachment.bin>