Author vstinner
Recipients diekhans, gregory.p.smith, vstinner
Date 2020-12-25.11:17:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1608895045.24.0.185819658747.issue38435@roundup.psfhosted.org>
In-reply-to
Content
> Using an intermediate shell script wrapper that changes the rlimit and exec's the actual process is also an alternative.

IMO using Python is more portable than relying on a shell.

I dislike relying on a shell since shells are not really portable (behave differently), unless you restrict yourself to a strict POSIX subset of the shell programming language. While '/bin/sh' is available on most Unix, Android uses '/system/bin/sh', and Windows and VxWorks have no shell (Windows provides cmd.exe which uses Batch programming language, and there are other scripting languages like VBS or PowerShell: so you need a complete different implementation for Windows).

For the oslo.concurrency project, I wrote the Python script prlimit.py: a wrapper calling resource.setrlimit() and then execute a new program. It's similar to the Unix prlimit program, but written in Python to be portable (the "prlimit" program is not available on all platforms).

https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/prlimit.py

I suggest to not provide a builtin wrapper to replace preexec_fn, but suggest replacements in the subprocess and What's New in Python 3.11 documentation (explain how to port existing code).

More generally, the whole preeexc_fn feature could be reimplemented a third-party project by spawning a *new* Python process, run the Python code, and *then* execute the final process. The main feature of preexec_fn is to give the ability to run a function of the current process, whereas what I'm discussing would be code written as a string.

--

preexec_fn can be used for non-trivial issues like only sharing some Windows HANDLE, see:
https://www.python.org/dev/peps/pep-0446/#only-inherit-some-handles-on-windows

Note: This specific problem has been solved the proper way in Python by adding support for PROC_THREAD_ATTRIBUTE_HANDLE_LIST in subprocess.STARTUPINFO: lpAttributeList['handle_list'] parameter.
History
Date User Action Args
2020-12-25 11:17:25vstinnersetrecipients: + vstinner, gregory.p.smith, diekhans
2020-12-25 11:17:25vstinnersetmessageid: <1608895045.24.0.185819658747.issue38435@roundup.psfhosted.org>
2020-12-25 11:17:25vstinnerlinkissue38435 messages
2020-12-25 11:17:24vstinnercreate