Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intent to approve PEP 703: making the GIL optional

discuss.python.org

Post reply on HN
Print view View original

111–120 of 513 posts

Re: Intent to approve PEP 703: making the GIL optional

#111

Post by xerxes901 »

miraculixx wrote: post #16

Unpopular opinion: This is a missed opportunity. What? Python could have been the one language with a sane multithreading model. Now it risks becoming a second version of Java. I fear this will make it a less attractive programming language, not least because it might lose its beginner friendlyness. For example, without the GIL a lot more care must be put into designing your programs. This can be true even though you…

> a per-thread GIL with an explicit mode to share particular objects

This is like Ruby's Ractors and I haven't really seen that be super successful so far. The "Objects" that need to be shared are things like class definitions, etc.... there are a ton of subtle issues with objects that are being marked as sharable when they should really not be or vice versa.

Re: Intent to approve PEP 703: making the GIL optional

#112

Post by catnibbler »

Is it really too late to not do this ? The only reason to get rid of the GIL is to help threading, but that's not a thing we should be doing. Threads need to just die, and be replaced by something less idiotic. Seriously, having the CPU run fragments of your program at random, so that all the previously ordered pieces are now contending with each other and even themselves ? How can anyone not see that this is the stupidest idea in the world ?

Re: Intent to approve PEP 703: making the GIL optional

#113

Post by Jabrov »

catnibbler wrote: post #112

Is it really too late to not do this ? The only reason to get rid of the GIL is to help threading, but that's not a thing we should be doing. Threads need to just die, and be replaced by something less idiotic. Seriously, having the CPU run fragments of your program at random, so that all the previously ordered pieces are now contending with each other and even themselves ? How can anyone not see that this is the stu…

As opposed to?

Re: Intent to approve PEP 703: making the GIL optional

#114

Post by n2d4 »

travisjungroth wrote: post #82
Waterluvian wrote: post #23

I’m glad they’re very conscious about how easily this could turn into a Python 4 debacle. They’ll have to be intensely careful not to accidentally affect yes-GIL behaviour. All kinds of weird cases are possible if any sort of emulated GIL isn’t exactly like with a GIL.

I’ve seen no description of how this won’t be like 2 -> 3 except: 1. We don’t want it to be. 2. We’ll give up quickly if it is. Those are both important points. But there seems to be an important missing third piece of “and we’ll achieve this by…”.

Quoting my comment from elsewhere:

>I didn't dive deep on this, but I assume that GIL mode can still run anything, including no-GIL code (it is one of their promises, at least). So, unlike 2->3, there is forwards-compatibility.

>It also seems like the latter isn't meant as a replacement (for the moment), but rather as an option.

As long as GIL mode remains compatible with both old and new code, I see very little danger in having a no-GIL mode (besides hogging CPython maintainers' time).

Re: Intent to approve PEP 703: making the GIL optional

#115

Post by miraculixx »

qbasic_forever wrote: post #107
paulddraper wrote: post #63

Earlier quoted context omitted.

No-GIL mode is optional, and libraries will be marked "no-GIL compatible" and the ecosystem will gradually support more and more of these. No one's flipping a switch and breaking mountains of sketchy C.

That's the exact attitude that lead to decades of pain with the 2 to 3 transition and libraries though. There was zero plan for how to help libraries migrate from python 2 to 3, or more importantly how does one library support _both_ python 2 and 3 from one codebase as their users take time to switch their python interpretor. The attitude of "just turn off GIL if you don't need it, just use libraries that support tur…

Indeed. The burden is 2x at least. They already estimate it's going to take 5+ years, so that's 10x the cost of a current library. At least.

If the burden becomes too big, at some point people may find it is the easier option to switch to a different ecosystem. I hope not.

Re: Intent to approve PEP 703: making the GIL optional

#116

Post by qbasic_forever »

travisjungroth wrote: post #82
Waterluvian wrote: post #23

I’m glad they’re very conscious about how easily this could turn into a Python 4 debacle. They’ll have to be intensely careful not to accidentally affect yes-GIL behaviour. All kinds of weird cases are possible if any sort of emulated GIL isn’t exactly like with a GIL.

I’ve seen no description of how this won’t be like 2 -> 3 except: 1. We don’t want it to be. 2. We’ll give up quickly if it is. Those are both important points. But there seems to be an important missing third piece of “and we’ll achieve this by…”.

Agreed--there needs to be discussion and thought about how this impacts library maintainers. How do they tell users their library supports or doesn't support non-GIL mode? Will pypi have new metadata to specify and enforce projectsdependencies support non-GIL mode, or is it just a chaotic free for all where users have to figure that out themselves? How will a library author have one codebase that supports both GIL and non-GIL mode--will they effectively fork the code and maintain two codebases (yuck!) or will there be support for detecting GIL mode? How does this work for C extensions too? There's a ton of work to make this smooth for libraries and I really hope it is being thought through better than the python 2 to 3 story for library authors (which was no story and chaos).

Re: Intent to approve PEP 703: making the GIL optional

#117

Post by [deleted] »

winter_blue wrote: post #102
ggm wrote: post #33

Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them. String parsing which tokenised in-place. DNS calls which used static buffers…

I wonder why so many library developers even chose to build native libraries on the shaky and poorly-architected foundation that Python is. Even writing a JVM native JNI library would have allowed to avoid a lot of that pain (and the library would have been useable from Clojure, Kotlin , Scala, JRuby[1], Jython[2], Java, etc) without any painful threading issues. [1] which I’m aware of having been used in production…

[deleted]

Re: Intent to approve PEP 703: making the GIL optional

#118

Post by whalesalad »

slt2021 wrote: post #73
n2d4 wrote: post #66

Earlier quoted context omitted.

It's only about performance. asyncio is still inherently single-threaded, and hence also single core. multiprocessing is multi-core and hence better for performance, but each process is relatively heavy and there's additional overhead to shared memory. GIL multi-threading is both single-core and difficult to use correctly. No-GIL multi-threading is multi-core, though difficult to use. I don't know the Python implemen…

I would argue that if you have large concurrency and shared complex state - you better off use kafka and redis/memcached as a shared state - and design proper fan-out. This design scales much better for systems that will eventually overgrow one big machine. the No-GIL pytohn will be of no use, when you need to deploy your app across 100s machines. I understand people want to take advantage of all cores etc, but at la…

sometimes you need all of that data in-process. when you move that state into redis, you still need to perform i/o to access it. when speed matters, this is troublesome.

Re: Intent to approve PEP 703: making the GIL optional

#119

Post by mappu »

miraculixx wrote: post #17
mappu wrote: post #13

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.

How did it work out for PHP?

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-4106367...

2. https://www.php.net/manual/en/philosophy.parallel.php

Re: Intent to approve PEP 703: making the GIL optional

#120

Post by miraculixx »

qbasic_forever wrote: post #101
bjourne wrote: post #96

This can (and I think will) cause issues for C extensions because many are written without multi-threading in mind. Here is a small example which is unsafe if lst can be accessed from another thread: https://news.ycombinator.com/item?id=36649769 Note that the code may cause a context switch even today if the C code callbacks into Python bytecode (via a __del__ method) and the bytecode is long enough (100 instructions…

Yep there are a ton of issues like that to be found, and unfortunately they will manifest as difficult to find and debug race conditions. This is why the proposal and work is to make non-GIL mode entirely optional and not the default. It just means for the brave few that flip it on and use it, be prepared to spend a huge amount of time finding and fixing subtle race conditions in decades of old python library code. T…

The intent is to make no GIL the default eventually.
Post reply on HN