4 ms·

With PEP703 you would compile Python either for multi or single-threading mode. The mode affects the ABI and therefore which C extensions are available. Eventua

by mappu 3y ago

With PEP703 you would compile Python either for multi or single-threading mode. The mode affects the ABI and therefore which C extensions are available. Eventually all C extensions would have an available port to the new ABI. The chosen solution is similar to how PHP used TSRMLS_ macros in the Zend engine - if threadsafety (ZTS) was #defined, all functions took an extra thread context parameter, breaking ABI.

miraculixx 3y ago
How did it work out for PHP?
- no_wizard 3y ago
  Honestly it didn't. PHP didn't get threads. It did eventually get Fibers though, which I suppose may have been in part influenced by this work
- mappu 3y ago
  The main benefit of the threadsafe builds was reentrancy support for multithreaded web servers (e.g. IIS / some apache MPMs). They were only slightly slower for single-threaded code. The new PHP 8 fibers are only coroutines on a single thread, but PHP has had fork/join since 2001 (!), which works pretty well with Linux CoW. There has been a pthreads extension since about 2012. However keeping a 1:1 pthreads API prevents some optimization possibilities [1], so the new hotness is php-parallel [2], which will transparently copy closed-over variables to a subinterpreter. 1. https://github.com/krakjoe/pthreads/issues/929#issue-410636734 https://github.com/krakjoe/pthreads/issues/929#issue-4106367... 2. https://www.php.net/manual/en/philosophy.parallel.php https://www.php.net/manual/en/philosophy.parallel.php
samus 3y ago
All C extensions are available when running without GIL. A challenge for distribution is that all extensions will have to built twice to be compatible with the two Python builds. However, few source code changes are required where the developers don't want to make it compatible with running without GIL. Executing such extensions forces using the GIL for the whole interpreter, which is slower than the GIL-only build.

by mappu 3y ago

miraculixx 3y ago

How did it work out for PHP?

no_wizard 3y ago
Honestly it didn't. PHP didn't get threads. It did eventually get Fibers though, which I suppose may have been in part influenced by this work
mappu 3y ago
The main benefit of the threadsafe builds was reentrancy support for multithreaded web servers (e.g. IIS / some apache MPMs). They were only slightly slower for single-threaded code. The new PHP 8 fibers are only coroutines on a single thread, but PHP has had fork/join since 2001 (!), which works pretty well with Linux CoW. There has been a pthreads extension since about 2012. However keeping a 1:1 pthreads API prevents some optimization possibilities [1], so the new hotness is php-parallel [2], which will transparently copy closed-over variables to a subinterpreter. 1. https://github.com/krakjoe/pthreads/issues/929#issue-410636734 https://github.com/krakjoe/pthreads/issues/929#issue-4106367... 2. https://www.php.net/manual/en/philosophy.parallel.php https://www.php.net/manual/en/philosophy.parallel.php

samus 3y ago

All C extensions are available when running without GIL. A challenge for distribution is that all extensions will have to built twice to be compatible with the two Python builds. However, few source code changes are required where the developers don't want to make it compatible with running without GIL. Executing such extensions forces using the GIL for the whole interpreter, which is slower than the GIL-only build.