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

361–370 of 513 posts

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

#361

Post by miraculixx »

lraxny wrote: post #243

The ruling class in python-dev are populists who are not threading experts. Python is run by the wrong people. They will approve something if it serves a corporation. The submission here is likely CYA, so they can say that "they asked the community". There is no appreciation for people doing grassroots open source software. If Instagram can add another hack instead of switching to Java, it will be approved. It is imp…

I have the same impression though I think its not intentional or otherwise ill intended.

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

#362

Post by formerly_proven »

neilv wrote: post #61
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 remember scouring those C runtime docs, for every non-reentrant function. It might be what got me in the habit of checking docs when using some API that I know moderately well, just in case there's some important detail I missed before, or something had changed. Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice fea…

Python has many similar restrictions even in the language itself, they just tend to be exceptionally poorly documented.

For example, you can't safely use print in a Python signal handler, because the entire I/O system is not reentrant [1], yet the documentation shows doing this in a "how to do it properly" example [2] while explaining that it's horribly unsafe to throw from a signal handler, which is the default for SIGINT. (And also the reason why the threading module doesn't expose PyThreadState_SetAsyncExc). So despite appearances to the contrary (since the Python signal handler is invoked by the VM, it doesn't actually run in a signal handler context; the signal module registers a C handler which simply sets a flag that is checked by the VM every instruction), you should probably only do in a Python signal handler what you would do in C, which is very little. Set a flag or write to a pipe. Don't go around and call library functions.

[1] E.g. https://bugs.python.org/issue24283 [2] https://docs.python.org/3/library/signal.html#note-on-signal...

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

#363

Post by _flux »

slt2021 wrote: post #54

Naiive question: Who needs No-GIL when we have asyncio and multiprocessing packages ? never ever had a problem with GIL in python, always found a workaround just by spinning up ThreadPool or ProcessPool, and used async libraries when needed. is there any use case of No-GIL which is not solved by multiprocessing ? I thought Single threaded execution without overhead for concurrency primitives is the best way to high p…

I haven't use Python multiprocessing packages, so I need to ask, how does one do flexible work queues with them?

I mean a situation like where in threaded context there would be code like:

    def determine_quest_latency(quest_name: str) -> int:
        return other_thread.wait_sync_job(lambda context: context.ping_quest(quest_name))
..without needing to provide a protocol that covers each possible scenario the client might wish to execute in the process?

I believe the answer is "you don't", but passing functions in messages is a highly convenient way to structure code in a way that local decisions can stay local, instead of being interspersed around the codebase.

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

#364

Post by usrbinbash »

miraculixx wrote: post #327
usrbinbash wrote: post #304

Earlier quoted context omitted.

> It's "free" in the sense that you don't need to re-write large parts of the VM In that sense, never updating python again is "free" as well, because it would save the python devs the trouble of changing the interpreter. And yet I think we can all agree that Python benefits from the fact that we no longer use Python 3.5 > and teach the entire Python community how to safely write multi-threaded code People who don't…

Progress in the name if progress is rarely a good choice. The key question that remains unanswered is Why should Python even need a free threading model? There are no good answers afaik.

> There are no good answers afaik.

I shall be more than happy to provide them:

Supporting thread based parallelism is the norm among all mainstream PLs with the one inglorious exception of JS, which doesn't because it simply can't.

And Python already does support it, it simply is limited by a legacy design decision. That was okay in a bygone age when fast single core machines were still the norm, Python was primarily a scripting language for when bash wasn't enough, and most relevant webapps were IO bound.

Today, there simply is no excuse any more. Python is the most ubiquitous language in the world, and running scaling web applications, is the lingua franca of ML, and orchestrates huge systems. Servers have hundreds of cores, and CPU bound workloads become ever more important.

It's about time Python rids itself of that needless limitation.

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

#365

Post by miraculixx »

mepian wrote: post #19

I wonder if there will ever be Python 4, it seems that the core developers want to avoid bumping the major version number ever again after 3 under any circumstances.

Yes bc they fear a Py3 to 4 transition would be perceived as a major burden.

I'm afraid we'll soon learn its not the version # that's burdensome, but the real or perceived(!) incompatibility between versions.

I wonder if introducing such a monumental change in a build flag of the minor version is really wise. Certainly its not in line with any interpretation of semantic versioning (to be fair I think the PSF does not claim to use that).

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

#366

Post by usrbinbash »

miraculixx wrote: post #329
usrbinbash wrote: post #304

Earlier quoted context omitted.

> It's "free" in the sense that you don't need to re-write large parts of the VM In that sense, never updating python again is "free" as well, because it would save the python devs the trouble of changing the interpreter. And yet I think we can all agree that Python benefits from the fact that we no longer use Python 3.5 > and teach the entire Python community how to safely write multi-threaded code People who don't…

> The GIL doesn't prevent race conditions between individual python instructions Yes it does. Unless we mean something different?

> Yes it does.

No, it doesn't.

    def thread_function():

        # thread may lose core here
        value = store.get_value() # or anywhere inside get_value

        # or here
        update(value) # or anywhere inside update()

        # or here
        store.put_value(value) # or anywhere inside put_value()
The GIL only makes certain internal functionality atomic. It doesn't protect the implemented logic from causing a race condition.

So unless I protect store with a lock, I can already get a race condition, GIL or no GIL.

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

#367

Post by usrbinbash »

csmpltn wrote: post #324
usrbinbash wrote: post #304

Earlier quoted context omitted.

> It's "free" in the sense that you don't need to re-write large parts of the VM In that sense, never updating python again is "free" as well, because it would save the python devs the trouble of changing the interpreter. And yet I think we can all agree that Python benefits from the fact that we no longer use Python 3.5 > and teach the entire Python community how to safely write multi-threaded code People who don't…

> "And as outlined above, these means are no suitable replacement for true thread based parallelism." Your only argument is that "thread-based parallelism can't be achieved without threads", but that's not relevant to the conversation whatsoever. The fact of the matter is that Python (already today) allows you to achieve parallelism across both IO-bound and CPU-bound workloads. For CPU-bound workloads, the number of…

> The fact of the matter is that Python (already today) allows you to achieve parallelism across both IO-bound and CPU-bound workloads.

I also don't need to use goroutines. I could simply spin up my golang application as a couple of processes, and use pipes and other IPC to coordinate them.

"There is another way to do X" doesn't imply that other way is better.

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

#368

Post by xmcqdpt2 »

sverhagen wrote: post #351
JonChesterfield wrote: post #241

Earlier quoted context omitted.

I can see system level python installs being abandoned. They seem to be getting progressively harder to use over time. I don't see the replacement being virtual env, it'll be a different language ecosystem. Whichever one looks like it has remembered "easy to do simple things in" is a feature.

While Python has never been my primary coding language, I've used it extensively for building scripts and tools, but I've pretty much given up on it. The language is so elegant, but the installation of it (with 2~3 compatibility issues being just a small part of that) just became such a turnoff. It's been super frustrating having to search the Internet every time I need to install something Python-related, to then fi…

The new official Scala build tool / compiler front end (scala-cli) is amazing,

https://scala-cli.virtuslab.org/

The thing that really struck me after years of python is how it lets you out dependencies directly in a comment on top of a script and it will download and run with them automatically, without poisoning any system settings. It's so simple!

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

#369

Post by the8472 »

weinzierl wrote: post #293
neilv wrote: post #61

Earlier quoted context omitted.

I remember scouring those C runtime docs, for every non-reentrant function. It might be what got me in the habit of checking docs when using some API that I know moderately well, just in case there's some important detail I missed before, or something had changed. Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice fea…

That Java had concurrency built in from the start is a blessing mostly, but also a bit of a curse. Most of the Java ecosystem is still in the mindset that threads are cheap and firing up a couple more cannot hurt. So we end up with apps that run thousands of threads and this disease is hard to contain.

Threads are cheap compared to the process-per-request model that came before. And they're easy to code for, you don't have to worry about blocking code or awaiting your futures in the correct way or things like that. They're not optimal if you want to squeeze lots of concurrent requests into some memory-limited box. But on the other hand even dumb threading offers more throughput than python or node.

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

#370

Post by usrbinbash »

miraculixx wrote: post #333
usrbinbash wrote: post #277

Earlier quoted context omitted.

> Parallelize at the fork level IPC is a PITA, and orchestrating processes is even worse. > or at the isolated numeric library level Not everything I want to parallelise in python runs in numpy. Simple example: WebService Backends. I have a 64 core server running a Werkzeug/Gunicorn application. The Service is mostly doing CPU bound tasks (data aggregation and analysis), so asyncio is pointless. What happens is, it r…

You would be well served with arena based (shared) object allocation and a gil per thread model. No need to draw everyone else into this.

> No need to draw everyone else into this

Please explain who exactly is "drawn into this"?

If you want to use async, this change doesn't affect your code.

If you want to use multiprocessing, this change doesn't affect your code.

Even if you already use threading, and do it correctly, this change doesn't actually affect your code.

So who is "drawn into this"? And please don't say library developers. a) Having to update libraries to have them remain relevant, is normal procedure, in all languages. b) a lot of the people who want this to change are library devs.

Post reply on HN