11 ms·
There's nothing wrong with the GIL as long as you know its there. It makes writing concurrent code in Python semi-magical and thats a huge benefit. Concurrent !
by Uptrenda 7y ago
There's nothing wrong with the GIL as long as you know its there. It makes writing concurrent code in Python semi-magical and thats a huge benefit. Concurrent != parallel though, so if there's really a need to scale up to multiple cores there's always the option of forking with multi-processing or "sub interpreters."
I can think of maybe having network code run in their own process and the UI in another. That way there's no risk of bottle necks slowing down the UI and transfers are likewise protected. If you look at bottle.py it seems that this approach could add A LOT of performance for managing downloads / uploads if it's done right.
- weberc2 7y agoHow does the GIL help you write concurrent code?
- dual_basis 7y agoIt means you never have to worry about message passing or locks, because they aren't a thing at all. On the other hand, what looks like concurrent code often isn't, and is actually run slower than single process code, also because of the GIL.
- weberc2 7y agoThat reduces to "you don't have to worry about performance because the GIL doesn't let you write performant code". That's not what I think of as "helpful".