Date: Sat, 22 Dec 2018 00:22:20 +0000 From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 221700] lang/python??: subprocess does not use closefrom, calls close(2) hundreds of thousands of times Message-ID: <bug-221700-21822-qIx1gXjKJZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-221700-21822@https.bugs.freebsd.org/bugzilla/> References: <bug-221700-21822@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221700 Kubilay Kocak <koobs@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|python@FreeBSD.org |koobs@FreeBSD.org --- Comment #16 from Kubilay Kocak <koobs@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 w= ill 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 (curre= ntly 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 pat= ches we create). 5) At present we need a patch in a form similar to (3) that I can get upstr= eam feedback on. With a patch reasonably close to (3) we can also consider carr= ying 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 exampl= es 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? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-221700-21822-qIx1gXjKJZ>