Hello Python list,
I intend to cross-compile Python v3.6.6 to Threos ( https://threos.io ) operating system. Threos is supports a quite large set from POSIX and C89/C99. Unfortunately, Threos lacks fork(2), but provides posix_spawn(3) instead. I already made some local changes in posixmodule.c to compile due to some features are detected as present but actually not supported, like HAVE_FORK -- I blame autotools for this :-). I don't know, however, whether the Python shall cross-compile without issues.
My question is that the _posixsubprocess.c can be prepared to use posix_spawn(3) instead of fork(2)? Maybe the UNIX/Linux version can also benefit from it, see: https://salsa.debian.org/ruby-team/ruby-posix-spawn
Best regards, Aron
On Sun, Jul 29, 2018 at 5:44 PM, Barath Aron baratharon@caesar.elte.hu wrote:
My question is that the _posixsubprocess.c can be prepared to use posix_spawn(3) instead of fork(2)? Maybe the UNIX/Linux version can also benefit from it, see: https://salsa.debian.org/ruby-team/ruby-posix-spawn
There is an open issue to add os.posix_spawn() at https://bugs.python.org/issue20104
--Berker
On 07/29/2018 06:02 PM, Berker Peksağ wrote:
There is an open issue to add os.posix_spawn() at https://bugs.python.org/issue20104
Seems promising, but 3.7 does not support it. And I don't see whether Python will work without fork(). - bpo-20104: Expose posix_spawn as a low level API in the os module. (removed before 3.7.0rc1)
--Berker
Aron
Python 3.8 will support os.posix_spawn(). I would like to see it used whenever possible instead of fork+exec, since it's faster and it can be safer on some platforms. Pablo Salgado is your guy for that.
Victor
On 07/30/2018 10:23 AM, Victor Stinner wrote:
Python 3.8 will support os.posix_spawn(). I would like to see it used whenever possible instead of fork+exec, since it's faster and it can be safer on some platforms. Pablo Salgado is your guy for that.
Victor
Awesome! Will this backported to 2.7? Or people should forget 2.7?
Aron
Supporting a new platform requires a lot work. It would be more reasonable for you to first try to get a good support of the master branch before start thinking how to support Python versions.
Python 2.7 in 2018? Really? Tick tock: https://pythonclock.org/ http://python3statement.org/
Usually, we don't support new platforms in CPython without strong support of a core developer. See the PEP 11 for more conditions like buildbot requirement. I suggest you to start working on a fork of CPython and maintain your changes in a branch. Git rebase makes it easy.
Victor
Le lundi 30 juillet 2018, Barath Aron baratharon@caesar.elte.hu a écrit :
On 07/30/2018 10:23 AM, Victor Stinner wrote:
Python 3.8 will support os.posix_spawn(). I would like to see it used
whenever possible instead of fork+exec, since it's faster and it can be safer on some platforms. Pablo Salgado is your guy for that.
Victor
Awesome! Will this backported to 2.7? Or people should forget 2.7?
Aron
On 7/30/2018 4:26 AM, Barath Aron wrote:
On 07/30/2018 10:23 AM, Victor Stinner wrote:
Python 3.8 will support os.posix_spawn(). I would like to see it used whenever possible instead of fork+exec, since it's faster and it can be safer on some platforms. Pablo Salgado is your guy for that.
Victor
Awesome! Will this backported to 2.7? Or people should forget 2.7?
Normally, enhancements are not backported anywhere. New API == new version of Python. You can, and people and organizations do, compile your own customized version.
Official (pydev) bugfixes for 2.7 end 1 Jan 2020. Many projects have already stopped or will stop before then fixing 2.7 versions of their packages. But some people will probably use it for at least another decade. Do what is best for you.
-
Barath Aron -
Berker Peksağ -
Terry Reedy -
Victor Stinner