How to break while loop based on events raised in a thread (Python 2.7)

ow I perform multiple checks at each if or while statement, but is there a IO async based method that breaks out of the loop when the event is raised in the thread? -- https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] How to stop a specific thread in Python 2.7?

Thank you for the hint ! On Fri, Oct 04, 2024 at 09:17:19AM GMT, Cameron Simpson wrote: On 03Oct2024 22:12, Dan Ciprus (dciprus) wrote: I'd be interested too :-). Untested sketch: def make_thread(target, *a, E=None, **kw): ''' Make a new Event E and T

Re: [Tutor] How to stop a specific thread in Python 2.7?

On 03Oct2024 22:12, Dan Ciprus (dciprus) wrote: I'd be interested too :-). Untested sketch: def make_thread(target, *a, E=None, **kw): ''' Make a new Event E and Thread T, pass `[E,*a]` as the target positional arguments. A shared p

Re: [Tutor] How to stop a specific thread in Python 2.7?

I'd be interested too :-). On Thu, Sep 26, 2024 at 03:34:05AM GMT, marc nicole via Python-list wrote: Could you show a python code example of this? On Thu, 26 Sept 2024, 03:08 Cameron Simpson, wrote: On 25Sep2024 22:56, marc nicole wrote: >How to create a per-thread event in Py

Re: How to stop a specific thread in Python 2.7?

That's one of the "disadvantages" of threads: you cannot safely stop a thread. Of course you could try, but that's never a good idea. The reason for this is that threads share memory. They might be holding locks that, if killed, will never be unlocked. They might (partiall

Re: [Tutor] How to stop a specific thread in Python 2.7?

Could you show a python code example of this? On Thu, 26 Sept 2024, 03:08 Cameron Simpson, wrote: > On 25Sep2024 22:56, marc nicole wrote: > >How to create a per-thread event in Python 2.7? > > Every time you make a Thread, make an Event. Pass it to the thread > worker funct

Re: How to stop a specific thread in Python 2.7?

On 25Sep2024 22:56, marc nicole wrote: How to create a per-thread event in Python 2.7? Every time you make a Thread, make an Event. Pass it to the thread worker function and keep it to hand for your use outside the thread. -- https://mail.python.org/mailman/listinfo/python-list

Re: How to stop a specific thread in Python 2.7?

How to create a per-thread event in Python 2.7? On Wed, 25 Sept 2024, 22:47 Cameron Simpson via Python-list, < python-list@python.org> wrote: > On 25Sep2024 19:24, marc nicole wrote: > >I want to know how to kill a specific running thread (say by its id) > > > >for

Re: How to stop a specific thread in Python 2.7?

On 25Sep2024 19:24, marc nicole wrote: I want to know how to kill a specific running thread (say by its id) for now I run and kill a thread like the following: # start thread thread1 = threading.Thread(target= self.some_func(), args=( ...,), ) thread1.start() # kill the thread event_thread1

How to stop a specific thread in Python 2.7?

Hello guys, I want to know how to kill a specific running thread (say by its id) for now I run and kill a thread like the following: # start thread thread1 = threading.Thread(target= self.some_func(), args=( ...,), ) thread1.start() # kill the thread event_thread1 = threading.Event

Re: python C-api and thread

> On 6 Aug 2024, at 07:11, aotto1968 via Python-list > wrote: > > I know but I use a thread like a process because the "conversation" between > the threads is done by my > software. a Thread is usually faster to startup (thread-pool) this mean for > high-lo

Re: python C-api and thread

On 06.08.24 04:34, Grant Edwards wrote: On 2024-08-05, aotto1968 via Python-list wrote: Is it possible to run two completely independent Python interpreters in one process, each using a thread? By independent, I mean that no data is shared between the interpreters and thus the C API can be

Re: python C-api and thread (Posting On Python-List Prohibited)

On 06.08.24 02:32, Lawrence D'Oliveiro wrote: On Mon, 5 Aug 2024 23:19:14 +0200, aotto1968 wrote: Is it possible to run two completely independent Python interpreters in one process, each using a thread? By independent, I mean that no data is shared between the interpreters and thus the

Re: python C-api and thread

On Tue, 6 Aug 2024 at 08:48, aotto1968 via Python-list wrote: > > hi, > > Is it possible to run two completely independent Python interpreters in one > process, each using a thread? > > By independent, I mean that no data is shared between the interpreters and > th

Re: python C-api and thread

On 2024-08-05, aotto1968 via Python-list wrote: > Is it possible to run two completely independent Python interpreters > in one process, each using a thread? > > By independent, I mean that no data is shared between the > interpreters and thus the C API can be used without any ot

python C-api and thread

hi, Is it possible to run two completely independent Python interpreters in one process, each using a thread? By independent, I mean that no data is shared between the interpreters and thus the C API can be used without any other "lock/GIL" etc. mfg -- https://mail.python.o

Re: Using a background thread with asyncio/futures with flask

On 2024-03-23 3:25 PM, Frank Millman via Python-list wrote: It is not pretty! call_soon_threadsafe() is a loop function, but the loop is not accessible from a different thread. Therefore I include a reference to the loop in the message passed to in_queue, which in turn passes it to

Re: Using a background thread with asyncio/futures with flask

's ideas, here is a version that works. It is not pretty! call_soon_threadsafe() is a loop function, but the loop is not accessible from a different thread. Therefore I include a reference to the loop in the message passed to in_queue, which in turn passes it to out_queue. Frank ==

Re: Using a background thread with asyncio/futures with flask

rinting out, the `final result = await future` doesn't seem to be happy here. Maybe someone sees something obvious I'm doing wrong here? I presume I'm mixing threads and asyncio in a way I shouldn't be. Aside from possible issues mixing threads and asyncio (I'

Re: Using a background thread with asyncio/futures with flask

dieter.mau...@online.de wrote at 2024-3-22 18:28 +0100: >Thomas Nyberg wrote at 2024-3-22 11:08 +0100: >> ... `future` use across thread boundaries ... >> Here's an example using just the standard library that >> exhibits the same issue: > ... >For use across thread

Re: Using a background thread with asyncio/futures with flask

Thomas Nyberg wrote at 2024-3-22 11:08 +0100: > ... `future` use across thread boundaries ... > Here's an example using just the standard library that > exhibits the same issue: I think all `asyncio` objects (futures, tasks, ...) are meant to be used in a single thread. If you u

Re: Using a background thread with asyncio/futures with flask

On 2024-03-22 1:23 PM, Frank Millman via Python-list wrote: On 2024-03-22 12:09 PM, Frank Millman via Python-list wrote: I am no expert. However, I do have something similar in my app, and it works. I do not use 'await future', I use 'asyncio.wait_for(future)'. I tested it and it did not

Re: Using a background thread with asyncio/futures with flask

On 2024-03-22 12:09 PM, Frank Millman via Python-list wrote: I am no expert. However, I do have something similar in my app, and it works. I do not use 'await future', I use 'asyncio.wait_for(future)'. I tested it and it did not work. I am not sure, but I think the problem is that you hav

Re: Using a background thread with asyncio/futures with flask

Sorry, must have missed that :-/ Lars Liedtke Lead Developer [Tel.] +49 721 98993- [Fax] +49 721 98993- [E-Mail]l...@solute.de solute GmbH Zeppelinstraße 15 76185 Karlsruhe Germany [Marken] Geschäftsführer | Managing Director: Dr. Thilo Gans, Bernd Vermaate

Re: Using a background thread with asyncio/futures with flask

On 2024-03-20 10:22 AM, Thomas Nyberg via Python-list wrote: Hello, I have a simple (and not working) example of what I'm trying to do. This is a simplified version of what I'm trying to achieve (obviously the background workers and finalizer functions will do more later): `app.py` ``` imp

Re: Using a background thread with asyncio/futures with flask

Hi, Yeah so flask does support async (when installed with `pip3 install flask[async]), but you are making a good point that flask in this case is a distraction. Here's an example using just the standard library that exhibits the same issue: `app.py` ``` import asyncio import threading import

Re: Using a background thread with asyncio/futures with flask

On Fri, 22 Mar 2024 at 18:35, Lars Liedtke via Python-list wrote: > > Hey, > > As far as I know (might be old news) flask does not support asyncio. > > You would have to use a different framework, like e.g. FastAPI or similar. > Maybe someone has already written "flask with asyncio" but I don't k

Re: Using a background thread with asyncio/futures with flask

Hey, As far as I know (might be old news) flask does not support asyncio. You would have to use a different framework, like e.g. FastAPI or similar. Maybe someone has already written "flask with asyncio" but I don't know about that. Cheers Lars Lars Liedtke Lead Developer [Tel.] +49 721 9

Using a background thread with asyncio/futures with flask

Hello, I have a simple (and not working) example of what I'm trying to do. This is a simplified version of what I'm trying to achieve (obviously the background workers and finalizer functions will do more later): `app.py` ``` import asyncio import threading import time from queue import Qu

[dead thread] Re: What is Install-Paths-To in WHEEL file?

This thread is no longer being useful, and is now closed. -- ~Ethan~ Moderator -- https://mail.python.org/mailman/listinfo/python-list

Re: What kind of "thread safe" are deque's actually?

On Thu, 30 Mar 2023 at 07:36, Greg Ewing via Python-list wrote: > > On 30/03/23 6:13 am, Chris Angelico wrote: > > I'm not sure what would happen in > > a GIL-free world but most likely the lock on the input object would > > still ensure thread safety. > > In a

Re: What kind of "thread safe" are deque's actually?

On 30/03/23 6:13 am, Chris Angelico wrote: I'm not sure what would happen in a GIL-free world but most likely the lock on the input object would still ensure thread safety. In a GIL-free world, I would not expect deque to hold a lock the entire time that something was iterating over it.

Re: What kind of "thread safe" are deque's actually?

nce_List call to (effectively) call list(data) to get a copy of it. It ought to be a thread-safe copy due to holding the GIL the entire time. I'm not sure what would happen in a GIL-free world but most likely the lock on the input object would still ensure thread safety. ChrisA Aah - thanks

Re: What kind of "thread safe" are deque's actually?

On Wed, 29 Mar 2023 10:50:49 -0400, Jack Dangler declaimed the following: >Sorry for any injected confusion here, but that line "data = >sorted(data)" appears as though it takes the value of the variable named >_data_, sorts it and returns it to the same variable store, so no copy >would be cr

Re: What kind of "thread safe" are deque's actually?

le name "data" is the parameter to median(), so it's whatever you ask for the median of. (I didn't make that obvious in my previous post - an excess of brevity on my part.) The sorted() function, UNlike list.sort(), returns a sorted copy of what it's given. I delved into the CP

Re: What kind of "thread safe" are deque's actually?

On 2023-03-29, Jack Dangler wrote: > >> data = sorted(data) > > Sorry for any injected confusion here, but that line "data = > sorted(data)" appears as though it takes the value of the variable named > _data_, sorts it and returns it to the same variable store, so no copy > would be create

Re: What kind of "thread safe" are deque's actually?

On 3/29/23 02:08, Chris Angelico wrote: On Wed, 29 Mar 2023 at 16:56, Greg Ewing via Python-list wrote: On 28/03/23 2:25 pm, Travis Griggs wrote: Interestingly the error also only started showing up when I switched from running a statistics.mean() on one of these, instead of what I had been

Re: What kind of "thread safe" are deque's actually?

On Wed, 29 Mar 2023 at 16:56, Greg Ewing via Python-list wrote: > > On 28/03/23 2:25 pm, Travis Griggs wrote: > > Interestingly the error also only started showing up when I switched from > > running a statistics.mean() on one of these, instead of what I had been > > using, a statistics.median()

Re: What kind of "thread safe" are deque's actually?

On 28/03/23 2:25 pm, Travis Griggs wrote: Interestingly the error also only started showing up when I switched from running a statistics.mean() on one of these, instead of what I had been using, a statistics.median(). Apparently the kind of iteration done in a mean, is more conflict prone than

Re: What kind of "thread safe" are deque's actually?

On 2023-03-27 at 18:25:01 -0700, Travis Griggs wrote: > "Deques support thread-safe, memory efficient appends and pops from > either side of the deque with approximately the same O(1) performance > in either direction.” > (https://docs.python.org/3.11/library/collections.htm

Re: What kind of "thread safe" are deque's actually?

On 2023-03-28, Travis Griggs wrote: > A while ago I chose to use a deque that is shared between two threads. I did > so because the docs say: > > "Deques support thread-safe, memory efficient appends and pops from > either side of the deque with approximately the same O

Re: What kind of "thread safe" are deque's actually?

On Tue, 28 Mar 2023 at 12:26, Travis Griggs wrote: > > A while ago I chose to use a deque that is shared between two threads. I did > so because the docs say: > > "Deques support thread-safe, memory efficient appends and pops from either > side of the deque with app

What kind of "thread safe" are deque's actually?

A while ago I chose to use a deque that is shared between two threads. I did so because the docs say: "Deques support thread-safe, memory efficient appends and pops from either side of the deque with approximately the same O(1) performance in either direction.” (https://docs.python.org

Re: Tkinter GUI freezing, used Thread then encountered RuntimeError: threads can only be started once

On 2023-01-11 00:13, Cameron Simpson wrote: On 10Jan2023 18:32, MRAB wrote: I don't like how you're passing Thread...start as an argument. IMHO, it would be better/cleaner to pass a plain function, even if the only thing that function does is to start the thread. Yes, and this is

Re: Tkinter GUI freezing, used Thread then encountered RuntimeError: threads can only be started once

On 10Jan2023 18:32, MRAB wrote: I don't like how you're passing Thread...start as an argument. IMHO, it would be better/cleaner to pass a plain function, even if the only thing that function does is to start the thread. Yes, and this is likely the thing causing the cited exceptio

Re: Tkinter GUI freezing, used Thread then encountered RuntimeError: threads can only be started once

['state'] = NORMAL button3['state'] = NORMAL button4['state'] = NORMAL ## button5 = Button( next_frame, width=20, text="next", fg="black", #command=lambda: change_flag(top_frame,bottom_frame

Tkinter GUI freezing, used Thread then encountered RuntimeError: threads can only be started once

'state'] = NORMAL button4['state'] = NORMAL ## button5 = Button( next_frame, width=20, text="next", fg="black", #command=lambda: change_flag(top_frame,bottom_frame,button1,button2,button3,button4,controller))

Re: memoization (original Subject lost because mailer lost the whole thread)

On 2022-09-19 17:31:31 +, Christman, Roger Graydon wrote: > And fortunately, Python makes memoization very easy, by using a > dictionary as a default value. I've done that often for classroom > purposes for cases where it makes a big difference (recursive > Fibonacci accelerates from exponent

Re: memoization (original Subject lost because mailer lost the whole thread)

"Hen Hanna" asked: > so... for a few days i've been revising this Code (in Gauche / Lisp / > Scheme) to make it run faster.. and last night i could improve it enough > to give me the result i wantedin 72 minutes or so (on my slow PC at > home). > ( Maybe... within a few months, i'll

Re: Simple message passing system and thread safe message queue

stand it is a > SSL client that sends messages to a server that implements a store of > messages. > > I would suggest to remove the sleep() calls and as a challenge for you, > make the server single-thread using asyncio and friends. > > Thanks, > Martin. > > On Mon

RE: Simple message passing system and thread safe message queue

3:35 (GMT+10:00) To: python-list Subject: Simple message passing system and thread safe message queue Hi.I wrote a couple of blog posts as I had to create a message passing system,and these posts are here:http://blogologue.com/search?category=1658082823X26Any comments or suggestions?Regards

Re: Simple message passing system and thread safe message queue

s and as a challenge for you, make the server single-thread using asyncio and friends. Thanks, Martin. On Mon, Jul 18, 2022 at 06:31:28PM +0200, Morten W. Petersen wrote: Hi. I wrote a couple of blog posts as I had to create a message passing system, and these posts are here: http://blogologue.

Simple message passing system and thread safe message queue

Hi. I wrote a couple of blog posts as I had to create a message passing system, and these posts are here: http://blogologue.com/search?category=1658082823X26 Any comments or suggestions? Regards, Morten -- I am https://leavingnorway.info Videos at https://www.youtube.com/user/TheBlogologue T

Re: c bindings with non-python thread callback while python exits

ing is > running. However, when the program terminates normally and there happens to > be one last callback underway, the c bindings hang. When viewed with GDB, I > can see that the callback thread callstack looks like this: > > futex_abstimed_wait_cancelable() > _pthread_cond

c bindings with non-python thread callback while python exits

the c bindings hang. When viewed with GDB, I can see that the callback thread callstack looks like this: futex_abstimed_wait_cancelable() _pthread_cond_wait_common() __pthread_cond_timedwait() PyCOND_TIMEDWAIT() take_gil() PyEval_RestoreThread() PyGILState_Ensure() c_bindings_callback() cpp_library_cal

Multiple event loops within the same thread ?

Hi all, It's possible to create several event loops in the same thread by calling asyncio.new_event_loop() Question: is there any use case where that could be useful ? Thank you in advance -- ∞ -- https://mail.python.org/mailman/listinfo/python-list

Re: Lock acquisition by the same thread - deadlock protection

Cameron Simpson wrote at 2020-3-15 10:17 +1100: >On 12Mar2020 20:08, Dieter Maurer wrote: > ... >>The documentation for the basic lock explicitely allows >>lock release by a foreign thread. >>As I understand the documentation, this lock type is by design >>very ba

Re: Lock acquisition by the same thread - deadlock protection

exception immediately on this erroneous situation. I thought it could be altered, or at least we could add an option to let a `threading.Lock` behave like a pthread mutex in mode `PTHREAD_MUTEX_ERRORCHECK`: Disallow double locking by same thread, disallow unlocking by another thread. The documen

Re: Lock acquisition by the same thread - deadlock protection

this >erroneous situation. >I thought it could be altered, or at least we could add an option to >let a `threading.Lock` behave like a pthread >mutex in mode `PTHREAD_MUTEX_ERRORCHECK`: Disallow double locking by >same thread, disallow unlocking >by another thread. The documentati

Re: Lock acquisition by the same thread - deadlock protection

tion immediately on this > erroneous situation. > I thought it could be altered, or at least we could add an option to > let a `threading.Lock` behave like a pthread > mutex in mode `PTHREAD_MUTEX_ERRORCHECK`: Disallow double locking by > same thread, disallow unlocking > by

Re: Lock acquisition by the same thread - deadlock protection

at least we could add an option to let a `threading.Lock` behave like a pthread mutex in mode `PTHREAD_MUTEX_ERRORCHECK`: Disallow double locking by same thread, disallow unlocking by another thread. However, after searching a bit more, I found a reference mentioning current behavior in a docstring de

Re: Lock acquisition by the same thread - deadlock protection

> On 9 Mar 2020, at 22:53, Yonatan Goldschmidt > wrote: > > I recently debugged a program hang, eventually finding out it's a deadlock of > a single thread, > resulting from my usage of 2 libraries. One of them - call it library A - is > reentrant & runs code

Re: Lock acquisition by the same thread - deadlock protection

com> wrote: > >> I recently debugged a program hang, eventually finding out it's a >> deadlock of a single thread, >> resulting from my usage of 2 libraries. One of them - call it library A - >> is reentrant & runs code in >> GC finalizers, while the oth

Re: Lock acquisition by the same thread - deadlock protection

This should be what you need. https://python-reference.readthedocs.io/en/latest/docs/functions/super.html On Tue, 10 Mar, 2020, 7:02 am Yonatan Goldschmidt, < yon.goldschm...@gmail.com> wrote: > I recently debugged a program hang, eventually finding out it's a deadlock > o

Lock acquisition by the same thread - deadlock protection

I recently debugged a program hang, eventually finding out it's a deadlock of a single thread, resulting from my usage of 2 libraries. One of them - call it library A - is reentrant & runs code in GC finalizers, while the other - library B - is not reentrant at all. Library B held o

Re: This thread is closed [an actual new thread]

hank you. I don't want to imply an obligation for others, but I suggest it will be (beyond the short term) less painful for future thread-closing actions if that is documented in an official document at a known web page URL. So every time a moderator closes a thread, the me

Re: This thread is closed [an actual new thread]

On 10/02/2018 03:46 AM, Rhodri James wrote: On 02/10/18 01:02, Ethan Furman wrote: It should be interpreted as: - No further discussion should take place on this thread. - I've done what I can with the primitive tools at hand to block    any further discussion. - Continued considerate

Re: This thread is closed [an actual new thread]

On Tue, Oct 2, 2018 at 4:50 AM Rhodri James wrote: > > On what grounds are you suppressing debate? It is exactly and precisely > not irrelevant to Python, since it's discussing a Python-specific change > to known and understood computing terminology, and frankly the statement > "Continued conside

Re: This thread is closed [an actual new thread]

On 2018-10-02, Rhodri James wrote: > On 02/10/18 01:02, Ethan Furman wrote: > On what grounds are you suppressing debate? It is exactly and precisely > not irrelevant to Python, since it's discussing a Python-specific change > to known and understood computing terminology, and frankly the stat

Re: This thread is closed [an actual new thread]

On 02/10/2018 11:46, Rhodri James wrote: On 02/10/18 01:02, Ethan Furman wrote: On 10/01/2018 04:26 PM, Ben Finney wrote:  > Ethan Furman writes:  >> This thread is closed.  >  > Coming from a moderator of this forum, I don't know how that statement  > is to be int

Re: This thread is closed [an actual new thread]

On 02/10/18 01:02, Ethan Furman wrote: On 10/01/2018 04:26 PM, Ben Finney wrote: > Ethan Furman writes: >> This thread is closed. > > Coming from a moderator of this forum, I don't know how that statement > is to be interpreted. It should be interpreted as: - No fu

Re: This thread is closed [an actual new thread]

On 10/01/2018 04:26 PM, Ben Finney wrote: > Ethan Furman writes: >> This thread is closed. > > Coming from a moderator of this forum, I don't know how that statement > is to be interpreted. It should be interpreted as: - No further discussion should take place on this t

This thread is closed (was: [OT] master/slave debate in Python)

Ethan Furman writes: > This thread is closed. Coming from a moderator of this forum, I don't know how that statement is to be interpreted. Is that a statement that it is *impossible* (mechanically) to post replies in this thread? Across the different technologies that propogate this fo

python3.7 - how to open a new thread and close the old each click on a button?

hii all, python3.7 - how to open a new thread and close the old each click on a button? here is my code: # -*- coding: utf-8 -*- # Form implementation generated from reading ui file 'AlonStockMarket.ui' # # Created by: PyQt5 UI code generator 5.11.2 # # WA

Re: python 3.7 - I try to close the thread without closing the GUI is it possible?

On 09/15/2018 01:23 AM, Albert-Jan Roskam wrote: > > I try to close the thread without closing the GUI is it possible? > > > Qthread seems to be worth investigating: > https://medium.com/@webmamoffice/getting-started-gui-s-with-python-pyqt-qthread-class-1b796203c18c Or bette

Re: python 3.7 - I try to close the thread without closing the GUI is it possible?

Here's a small PyQt example of using Qt's asynchronous facilities: http://zetcode.com/pyqt/qnetworkaccessmanager/ That should get the original poster started. -- https://mail.python.org/mailman/listinfo/python-list

Re: python 3.7 - I try to close the thread without closing the GUI is it possible?

> I try to close the thread without closing the GUI is it possible? Qthread seems to be worth investigating: https://medium.com/@webmamoffice/getting-started-gui-s-with-python-pyqt-qthread-class-1b796203c18c -- https://mail.python.org/mailman/listinfo/python-list

Re: python 3.7 - I try to close the thread without closing the GUI is it possible?

alon.naj...@gmail.com writes: > python 3.7 - I try to close the thread without closing the GUI is it > possible? I assume that with "close a thread" you mean "terminate a thread". It is difficult to terminate a thread from the outside, because on many platforms, t

python 3.7 - I try to close the thread without closing the GUI is it possible?

python 3.7 - I try to close the thread without closing the GUI is it possible? here is my code, sorry I'm am new with python and generally with code XD . thanks all # -*- coding: utf-8 -*- # Form implementation generated from reading ui file 'AlonStockMarket.ui' # # Creat

Re: Why is multiprocessing.Queue creating a thread ?

On Sun, Jul 29, 2018 at 8:03 PM, Léo El Amri via Python-list wrote: > Hello list, > > This is a simple question: I wonder what is the reason behind > multiprocessing.Queue creating a thread to send objects through a > multiprocessing.connection.Connection. > I plan to implement

Why is multiprocessing.Queue creating a thread ?

Hello list, This is a simple question: I wonder what is the reason behind multiprocessing.Queue creating a thread to send objects through a multiprocessing.connection.Connection. I plan to implement an asyncio "aware" Connection class. And while reading the source code of the multi

Re: Thread-safe way to add a key to a dict only if it isn't already there?

eturned. > 2) The key did exist in the dictionary. The provided default is > ignored, and the previous value is returned. This is a classic test-and-set race condition: # Initially assert "A" not in d # Thread 1 d.setdefault("A", 1) # Thread 2 d[&qu

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Mon, Jul 9, 2018 at 5:18 AM, Marko Rauhamaa wrote: > Chris Angelico : >> Are you assuming that Python's semantics are defined by the semantics >> of one possible implementation language? > > What are Python's semantics defined by? I've been using these: > >https://docs.python.org/3/referenc

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Chris Angelico : > Are you assuming that Python's semantics are defined by the semantics > of one possible implementation language? What are Python's semantics defined by? I've been using these: https://docs.python.org/3/reference/> https://docs.python.org/3/library/> Unfortunately, neith

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Mon, Jul 9, 2018 at 4:57 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Mon, Jul 9, 2018 at 2:11 AM, Marko Rauhamaa wrote: >>> MRAB : In C you'd declare 'quit' as 'volatile' to tell the compiler that it could change unexpectedly, so don't make that assumption. >>> >>> C is an e

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Chris Angelico : > On Mon, Jul 9, 2018 at 2:11 AM, Marko Rauhamaa wrote: >> MRAB : >>> In C you'd declare 'quit' as 'volatile' to tell the compiler that it >>> could change unexpectedly, so don't make that assumption. >> >> C is an even tougher case. Even if the compiler kept on checking a >> vol

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 16:37:11 +0100, MRAB wrote: > On 2018-07-08 14:38, Steven D'Aprano wrote: >> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >> > [snip] >>> More importantly, this loop may never finish: >>> >>> # Init

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 19:35:55 +0300, Marko Rauhamaa wrote: > Steven D'Aprano : >> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >>> PS My example with "impossible" being the result of a racy integer >>> operation is of course unlikely but could be the outcome if the Python >>> runtime r

Re: Thread-safe way to add a key to a dict only if it isn't already there?

h: >>>> >>>> # Initially >>>> quit = False >>>> >>>> # Thread 1 >>>> global quit >>>> while not quit: >>>> time.sleep(1) >>>> >>>> # Thread 2 >>>&

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Steven D'Aprano : > On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >> PS My example with "impossible" being the result of a racy integer >> operation is of course unlikely but could be the outcome if the Python >> runtime reorganized its object cache on the fly (in a hypothetical >> impl

Re: Thread-safe way to add a key to a dict only if it isn't already there?

MRAB : > On 2018-07-08 14:38, Steven D'Aprano wrote: >> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >> > [snip] >>> More importantly, this loop may never finish: >>> >>> # Initially >>> quit = False >&g

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On 2018-07-08 14:38, Steven D'Aprano wrote: On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: [snip] More importantly, this loop may never finish: # Initially quit = False # Thread 1 global quit while not quit: time.sleep(1) # Thread 2 g

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: > Steven D'Aprano : >> Changing implementations from one which is thread safe to one which is >> not can break people's code, and shouldn't be done on a whim. >> Especially since such breakage could be

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Steven D'Aprano : > Changing implementations from one which is thread safe to one which is > not can break people's code, and shouldn't be done on a whim. > Especially since such breakage could be subtle, hard to notice, harder > to track down, and even harder still to f

Re: Thread-safe way to add a key to a dict only if it isn't already there?

ring to the variable we expected to contain 2, but it would have to do so by assignment, not by mucking about with the execution order of integer addition.) In the case of Example 17.4-1, starting with A = B = 0, two threads execute: Thread 1:r2 = A; B = 1; Thread 2:r1 = B; A =

Re: Thread-safe way to add a key to a dict only if it isn't already there?

Chris Angelico : > On Sun, Jul 8, 2018 at 11:04 AM, Steven D'Aprano > wrote: >>> The only thing Python should guarantee is that the data structures stay >>> "coherent" under race conditions. In other words, there cannot be a >>> segmentation fault. For example, if two threads executed this code i

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, Jul 8, 2018 at 1:58 PM, Steven D'Aprano wrote: > On Sun, 08 Jul 2018 12:23:41 +1000, Chris Angelico wrote: > >>> Some people, when confronted with a problem, say, "I know, I'll use >>> threads". Nothhtwo probw ey ave lems. >> >> Right. Now they have to deal with interleaving, but that's al

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 12:23:41 +1000, Chris Angelico wrote: >> Some people, when confronted with a problem, say, "I know, I'll use >> threads". Nothhtwo probw ey ave lems. > > Right. Now they have to deal with interleaving, but that's all. And > honestly, MOST CODE wouldn't notice interleaving; it'

Re: Thread-safe way to add a key to a dict only if it isn't already there?

ich basically means "mutable globals are a risk, pretty much everything else is safe". >> But you're absolutely right that there are only a small handful of >> plausible results, even with threading involved. > > Indeed. Even though threading is non-deterministic, it isn't *entirely* > unconstrained. > Yeah. Quite far from it, in fact. Python threading is well-defined and fairly easy to work with. Only in a handful of operations do you need to worry about atomicity - like the one that started this thread. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: Thread-safe way to add a key to a dict only if it isn't already there?

On Sun, 08 Jul 2018 11:15:17 +1000, Chris Angelico wrote: [...] > Python threads don't switch only between lines of code, As I understand it, there could be a switch between any two byte codes, or maybe only between certain bytes codes. But certain more fine grained than just between lines of

  1   2   3   4   5   6   7   8   9   10   >