STINNER Victor <vstin...@python.org> added the comment:
> I'm trying to make sure we track what is blocking people from getting rid of > preexec_fn in their existing code so that we can actually deprecate and get > rid of the API entirely. If you consider posix_spawn(), I think that a convenient replacement for preexec_fn function would be a wrapper process which would execute *arbitrary Python code* before spawning the program. It would not only cover umask case, but also prlimit, and another other custom code. Pseudo-code of the wrapper: import sys code = sys.argv[1] argv = sys.argv[2:] eval(code) os.execv(argv[0], argv) The main risk is that the arbitrary code could create an inheritable file descriptor (not all C extensions respect the PEP 446) which would survive after replacing the process memory with the new program. Such design would allow to implement it in a third party package (on PyPI) for older Python versions as well. -- Currently, preexec_fn is a direct reference to a callable Python object in the current process. preexec_fn calls it just after fork(). Here I'm talking about running arbitrary Python code in a freshly spawned Python process. It's different. -- The new problems are: * How to ensure that Python is configured as expected? Use -I command line option? Use -S to not import the site module? * How to report a Python exception from the child to the parent process? Build a pipe between the two processes and serialize the exception, as we are already doing for preexec_fn? * How to report os.execv() failure to the parent? Just something like sys.exit(OSErrno.errno)? * Should close_fds be implemented in the wrapper as well? If yes, can the parent avoid closing file descriptors? > https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/prlimit.py This wrapper uses os.execv(). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38417> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
