j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On Thu, Jun 27, 2019 at 1:36 PM Michael Foord firstname.lastname@example.org wrote:
On Thu, 27 Jun 2019 at 20:53, Yonatan Zunger email@example.com wrote:
Generally, threads don't have a notion of non-cooperative thread termination. This is because (unlike processes) threads share address spaces, and an unexpected termination of a thread can leave memory in arbitrary and unexpected states. (For example, what if one thread was holding a mutex when it got killed?)
That's precisely why thread cancellation in managed languages (like Python is) raise an exception to terminate the the thread and honour finally blocks.
There's one issue that Yonatan's post reminded me of though. Currently a thread that's locked in a mutex.acquire() operation cannot be interrupted by a signal at the Python level (unlike I/O, which can be interrupted -- IIRC Victor spent a lot of time making this work). There's a workaround (specify a timeout) but this is still something that would have to be solved for this to be useful.
-- --Guido van Rossum (python.org/~guido) Pronouns: he/him/his **(why is my pronoun here?) http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...