[flagged]
The first year of free-threaded Python
11–20 of 302 posts
Re: The first year of free-threaded Python
#12[flagged]
Maybe it's an aroused male snake. Looks like he's really into that bobbin!
Re: The first year of free-threaded Python
#13[flagged]
Perhaps is intentionally, to allude to the multithreaded nature of free-threaded Python.
Re: The first year of free-threaded Python
#14Earlier quoted context omitted.
how does the the language being dynamic negatively affect the complexity of multithreading?
Is there so much legacy python multithreaded code anyway? Considering everyone knew about the GIL, I'm thinking most people just wouldn't bother.
There is, and what's worse, it assumes a global lock will keep things synchronized.
Re: The first year of free-threaded Python
#15Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.
As a Python dabbler, what should I be reading to ensure my multi-threaded code in Python is in fact safe.
The literature on distributed systems is huge. It depends a lot on your use case what you ought to do. If you're lucky you can avoid shared state, as in no race conditions in either end of your executions.
https://www.youtube.com/watch?v=_9B__0S21y8 is fairly concise and gives some recommendations for literature and techniques, obviously making an effort in promoting PlusCal/TLA+ along the way but showcases how even apparently simple algorithms can be problematic as well as how deep analysis has to go to get you a guarantee that the execution will be bug free.
Re: The first year of free-threaded Python
#16This is some serious groundwork for the next era of performance!
Re: The first year of free-threaded Python
#17[flagged]
I thought it was a play on multiple threads. Besides why would it matter? This is to the same as someone saying when digital drawing came up that they can't take an article seriously because some fluffy drawing was digitally drawn instead of hand drawn on paper.
Re: The first year of free-threaded Python
#18Earlier quoted context omitted.
Is there so much legacy python multithreaded code anyway? Considering everyone knew about the GIL, I'm thinking most people just wouldn't bother.
There is, and what's worse, it assumes a global lock will keep things synchronized.
Does it? The GIL only ensured each interpreter instruction is atomic. But any group of instruction is not protected. This makes it very hard to rely on the GIL for synchronization unless you really know what you are doing.
Re: The first year of free-threaded Python
#19Does removal of the GIL have any other effects on multi-threaded Python code (other than allowing it to run in parallel)?
My understanding is that the GIL has lasted this long not because multi-threaded Python depends on it, but because removing it:
- Complicates the implementation of the interpreter
- Complicates C extensions, and
- Causes single-threaded code to run slower
Multi-threaded Python code already has to assume that it can be pre-empted on the boundary between any two bytecode instructions. Does free-threaded Python provide the same guarantees, or does it require multi-threaded Python to be written differently, e.g. to use additional locks?
Re: The first year of free-threaded Python
#20Earlier quoted context omitted.
As a Python dabbler, what should I be reading to ensure my multi-threaded code in Python is in fact safe.
The literature on distributed systems is huge. It depends a lot on your use case what you ought to do. If you're lucky you can avoid shared state, as in no race conditions in either end of your executions. https://www.youtube.com/watch?v=_9B__0S21y8 is fairly concise and gives some recommendations for literature and techniques, obviously making an effort in promoting PlusCal/TLA+ along the way but showcases how even…
My current concern is a CRUD interface that transcribes audio in the background. The transcription is triggered by user action. I need the "transcription" field disabled until the transcript is complete and stored in the database, then allow the user to edit the transcription in the UI.
Of course, while the transcription is in action the rest of the UI (Qt via Pyside) should remain usable. And multiple transcription requests should be supported - I'm thinking of a pool of transcription threads, but I'm uncertain how many to allocate. Half the quantity of CPUs? All the CPUs under 50% load?
Advise welcome!