BKL
BKL
Posted Feb 15, 2021 18:17 UTC (Mon) by corbet (editor, #1)In reply to: The GIL is far, far worse than that by ksandstr
Parent article: Speeding up CPython
Many of us have spent a lot of time complaining about the big kernel lock — and doing the work to get rid of it as well. That said, one shouldn't just poke at it this way. The BKL had a specific and well-defined purpose: allow most of the code in the kernel to continue to run as if it were on a uniprocessor machine, with all of the associated assumptions intact. It was, I believe, the only way to break the problem down into tractable steps.
Posted Feb 15, 2021 18:39 UTC (Mon)
by ksandstr (guest, #60862)
[Link]
The BKL was quick and nasty, and that didn't matter when the target hardware was two to four 386 on some crazy board with a bespoke multiprocessing architecture. Contrast with the GIL, which exists to push I/O multiplexing into the kernel and exploit concurrency in some FFI calls while (historically) avoiding concurrent reference counting misery.
Replacing the BKL is a problem involving primitives provided by the fixed processor architecture, which is necessarily unforgiving. On the other hand, replacing the GIL could be as simple as switching Python contexts in the interpreter, all on the same stack, and letting epoll (which didn't exist in 1996) handle the kernel part while FFI calls interact with their own concurrency models as they would in any other program.
Linus is not the goose, and Guido is not the gander. Heck, one of them isn't even warm-blooded.
BKL