[Bug 221700] lang/python??: subprocess does not use closefrom, calls close(2) hundreds of thousands of times

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sat Dec 22 00:22:22 UTC 2018


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221700

Kubilay Kocak <koobs at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|python at FreeBSD.org          |koobs at FreeBSD.org

--- Comment #16 from Kubilay Kocak <koobs at FreeBSD.org> ---
For explicitness and reference to future readers, current state is:

1) Yep, we're now comfortable that our closefrom(2) is async-signal safe
(thanks emaste, conrad, others)

2) Yep, we want to resolve this issue, it has high value. I'm happy to
coordinate and usher code into ports/upstream.

3) We want to resolve this in a manner upstream will accept. I think this will
be in the form of something like a configure check for closefrom(2) and
conditionals in code with HAVE_CLOSEFROM. If other platforms have closefrom(2)
but aren't signal safe (or there's no positive evidence they are), we could
additionally if && defined(__FreeBSD__) to be conservative in the first
instance. We need patches for each upstream supported Python version (currently
2.7, 3.6, 3.7, default (3.8))

4) I have a python bugs account, and have a good relationship with some core
devs, who I'd like to get input/direction from (both in general and for patches
we create).

5) At present we need a patch in a form similar to (3) that I can get upstream
feedback on. With a patch reasonably close to (3) we can also consider carrying
it locally in ports until upstream merges and releases future versions with
support. I need (C) help with this if the diffs in comments are only examples
and not 'complete/ready/finished'.

Open Questions:

Are there any places other than _posixsubprocess.c:_close_fds_by_brute_force
and posix_closerange() that might benefit from this?

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-python mailing list