Great post! One question that lingered for me is: what are asynchronous safe-points? The post goes into some detail about their synchronous counterparts
// 3. Asynchronous safe-points occur at any instruction in user code
// where the goroutine can be safely paused and a conservative
// stack and register scan can find stack roots. The runtime can
// stop a goroutine at an async safe-point using a signal.
> In WET code (write everything twice) everything looks primitive, as if it was written by complete newbie, and every change needs to be added at multiple places, but each change is trivial and time to finish is predictable. I would go as far as calling the code boring. The most difficult thing is to resist the temptation to remove the duplicity.
This only scales so far. After some point, it's very easy to run into cases where you meant to change something everywhere but forgot/didn't know about others. Not to say everything should be so compartmentalized as to restrict change, but there is a balance to be had.
I've never heard this one before, but I love it. Unfortunately we've also got "Don't Abstract Methods Prematurely" and "Descriptive And Meaningful Phrases".
Yes, what actually happens is that many code changes are released half-baked because logic only got updated in 1 (or 13) of the 14 places that needed to be updated, and the cussing and hair pulling just starts later.
Tests don't really help you when a newly discovered bug affects logic copied in ten places and you're only aware of two of them. You can add a regression test to the places that you update, but not the others. And then if there's another bug discovered in the duplicated code, a different subset of the copies might get changed and have tests added. Suddenly it looks like these different versions of the repeated logic are intended to be behaving differently for some unknown reason even though the divergence is purely accidental.
Pydantic falls into this box for me. The maintainer refuses to build API reference documentation, as they feel that there should only be one source of information. It's their project, of course, but every time I need to find a method on an object, I am scouring pages of prose for it. Sometimes it's just easier to read the source.
They don't benefit much from a lack of GIL, perhaps a small reduction in overhead. This feature is a first step towards being able to disable the GIL completely. It is intended to be implemented in a very conservative manner, bit by bit and so for this first step it should work for thread free code.
Disabling the GIL can unlock true multi-core parallelism for multi-threaded programs, but this requires code to be restructured for safe concurrency, which isn't that difficult it seems:
> When we found out about the “nogil” fork of Python it took a single person less than half a working day to adjust the codebase to use this fork and the results were astonishing. Now we can focus on data acquisition system development rather than fine-tuning data exchange algorithms.
>We frequently battle issues with the Python GIL at DeepMind. In many of our applications, we would like to run on the order of 50-100 threads per process. However, we often see that even with fewer than 10 threads the GIL becomes the bottleneck. To work around this problem, we sometimes use subprocesses, but in many cases the inter-process communication becomes too big of an overhead. To deal with the GIL, we usually end up translating large parts of our Python codebase into C++. This is undesirable because it makes the code less accessible to researchers.
Speed. Admittedly not quite as much so the way this patch is implemented, since it just short circuits the extra function calls, doesn’t omit them entirely.
Removing the GIL results in slower execution. Without the guarantees of single thread action, the interpreter needs to utilize more locks under the hood.
Umm, yes it does? For the longest time, Guido’s defense for the GIL was that all previous efforts resulted in an unacceptable hit to single threaded performance.
From when I was reading the proposal, the idea is that until a C extension is loaded, you can assume that there are no other threads. Then when a module is loaded, by default you assume that it uses threads but modules that are thread free can indicate that using a flag, so if a module indicates it's thread free then you continue running without the thread safety features.
I mean, you're not wrong, but also it's a huge feat to provide a toggle for a major feature like the GIL. Though, if it's just asyncio that's broken, perhaps it's not like removing your engine, but rather your antilock brakes :)
EDIT:
> [the test synchronous programs] all seem to run fine, and very basic threaded programs work, sometimes
