A single close(fd) syscall is cheap, but when MAXFDS (maximum file
descriptor number) is high, the loop calling close(fd) on each file
descriptor can take several milliseconds.
The default value of subprocess.Popen "close_fds" parameter changed to True
in Python 3. Compared to Python 2, close_fds=True can make Popen 10x
slower: see bpo-37790 [1]
The present workaround on FreeBSD to improve performance is to load and
mount the fdescfs kernel module, but this is not enabled by default.
This change adds minimum viable (and upstreamable) closefrom(2) syscall
support to Python's subprocess and posix modules, improving performance
significantly for loads that involve working with many processes, such as
diffoscope, ansible, and many others.
For additional optimizations, upstream recently (3.8) landed posix_spawn(2)
support [3] and has stated that they will adopt close_range(2) after Linux
merges it [4]. Linux/FreeBSD developers are already collaborating on
ensuring compatible implementations, with FreeBSD's implementation pending
in D21627. [5]
Thank you emaste, cem, kevans for providing analysis, input,
clarifications, comms/upstream support and patches.
[1] https://bugs.python.org/issue37790
[2] https://bugs.python.org/issue38061
[3] https://bugs.python.org/issue35537
[4] https://lwn.net/Articles/789023/
[5] https://reviews.freebsd.org/D21627
Additional References:
https://bugs.python.org/issue8052https://bugs.python.org/issue11284https://bugs.python.org/issue13788https://bugs.python.org/issue1663329https://www.python.org/dev/peps/pep-0446/
PR: 242274, 221700
Submitted by: kevans (emaste, cem)
Approved by: koobs (python (maintainer), santa)
When python3.?-config is symlinked to another location it starts
outputting bogus paths. For example
$ pwd
/home/tobias
$ python3.6-config --includes
-I/usr/local/include/python3.6m -I/usr/local/include/python3.6m
$ ln -s /usr/local/bin/python3.6-config python3-config
$ ./python3-config --includes
-I/home/include/python3.6m -I/home/include/python3.6m
This breaks ports trying to use BINARY_ALIAS together with
python3.?-config. Apply a patch to resolve the symlink first before
trying to find the install prefix.
PR: 229749
Submitted by: tobik
Reviewed by: antoine, miwi
Approved by: python (miwi)
- Move BROKEN_SSL upward
- Sort USES
- Remove CPE_*: all of them are default values
- Update PLIST_FILES: do not use %%
- Update http:// links in Makefile comments and patch files
Ports using USE_PYTHON=distutils are now flavored. They will
automatically get flavors (py27, py34, py35, py36) depending on what
versions they support.
There is also a USE_PYTHON=flavors for ports that do not use distutils
but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if
using distutils but flavors are not wanted.
A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
added to cope with Python ports that did not have the Python
PKGNAMEPREFIX but are flavored.
USES=python now also exports a PY_FLAVOR variable that contains the
current python flavor. It can be used in dependency lines when the
port itself is not python flavored. For example, deskutils/calibre.
By default, all the flavors are generated. To only generate flavors
for the versions in PYTHON2_DEFAULT and PYTHON3_DEFAULT, define
BUILD_DEFAULT_PYTHON_FLAVORS in your make.conf.
In all the ports with Python dependencies, the *_DEPENDS entries MUST
end with the flavor so that the framework knows which to build/use.
This is done by appending '@${PY_FLAVOR}' after the origin (or
@${FLAVOR} if in a Python module with Python flavors, as the content
will be the same). For example:
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}
PR: 223071
Reviewed by: portmgr, python
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12464
