Re: Look free ID genertion (was: Is there a more efficient threading lock?)

On Thu, 2 Mar 2023 12:45:50 +1100, Chris Angelico declaimed the following: > >As have all CPUs since; it's the only way to implement locks (push the >locking all the way down to the CPU level). > Xerox Sigma (circa 1970): Modify and Test (byte/halfword/word) Granted, that was a

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

On 2023-03-02, Chris Angelico wrote: > On Thu, 2 Mar 2023 at 08:01, <2qdxy4rzwzuui...@potatochowder.com> wrote: >> On 2023-03-01 at 14:35:35 -0500, >> avi.e.gr...@gmail.com wrote: >> > What would have happened if all processors had been required to have >> > some low level instruction that

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

On Thu, 2 Mar 2023 at 13:02, Weatherby,Gerard wrote: > > So I guess we know what would have happened. > Yep. It's not what I was talking about, but it's also a very important concurrency management feature. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

a more efficient threading lock?) *** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. *** On Thu, 2 Mar 2023 at 08:01, <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 2023-03-01 at 14:35:35 -0500, > avi.e.gr...@gmail.

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

On Thu, 2 Mar 2023 at 08:01, <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 2023-03-01 at 14:35:35 -0500, > avi.e.gr...@gmail.com wrote: > > > What would have happened if all processors had been required to have > > some low level instruction that effectively did something in an atomic > > way

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

On 2023-03-01 at 14:35:35 -0500, avi.e.gr...@gmail.com wrote: > What would have happened if all processors had been required to have > some low level instruction that effectively did something in an atomic > way that allowed a way for anyone using any language running on that > machine a way to

Re: Look free ID genertion (was: Is there a more efficient threading lock?)

On Thu, 2 Mar 2023 at 06:37, wrote: > > If a workaround like itertools.count.__next__() is used because it will not > be interrupted as it is implemented in C, then I have to ask if it would > make sense for Python to supply something similar in the standard library > for the sole purpose of a

RE: Look free ID genertion (was: Is there a more efficient threading lock?)

is very directly using the atomic operation directly. -Original Message- From: Python-list On Behalf Of Dieter Maurer Sent: Wednesday, March 1, 2023 1:43 PM To: Chris Angelico Cc: python-list@python.org Subject: Look free ID genertion (was: Is there a more efficient threading lock?) Chris

Look free ID genertion (was: Is there a more efficient threading lock?)

Chris Angelico wrote at 2023-3-1 12:58 +1100: > ... > The >atomicity would be more useful in that context as it would give >lock-free ID generation, which doesn't work in Python. I have seen `itertools.count` for that. This works because its `__next__` is implemented in "C" and therefore will not

Re: Is there a more efficient threading lock?

On Wed, 1 Mar 2023 at 10:04, Barry wrote: > > > Though it's still probably not as useful as you might hope. In C, if I > > can do "int id = counter++;" atomically, it would guarantee me a new > > ID that no other thread could ever have. > > C does not have to do that atomically. In fact it is

Re: Is there a more efficient threading lock?

> Though it's still probably not as useful as you might hope. In C, if I > can do "int id = counter++;" atomically, it would guarantee me a new > ID that no other thread could ever have. C does not have to do that atomically. In fact it is free to use lots of instructions to build the int value.

Re: Is there a more efficient threading lock?

On Mon, 27 Feb 2023 at 17:28, Michael Speer wrote: > > https://github.com/python/cpython/commit/4958f5d69dd2bf86866c43491caf72f774ddec97 > > it's a quirk of implementation. the scheduler currently only checks if it > needs to release the gil after the POP_JUMP_IF_FALSE, POP_JUMP_IF_TRUE, >

Re: Is there a more efficient threading lock?

k glance. > > I do agree that you shouldn't depend on this unless you find a written > guarantee of the behavior, as it is likely an implementation quirk of some > kind > > --[code]-- > > import threading > > UPDATES = 1000 > THREADS = 256 > > vv = 0

Re: Is there a more efficient threading lock?

guarantee of the behavior, as it is likely an implementation quirk of some kind --[code]-- import threading UPDATES = 1000 THREADS = 256 vv = 0 def update_x_times( xx ): for _ in range( xx ): global vv vv += 1 def main(): tts = [] for _ in range( THREADS

Re: Is there a more efficient threading lock?

On Mon, 27 Feb 2023 at 10:42, Jon Ribbens via Python-list wrote: > > On 2023-02-26, Chris Angelico wrote: > > On Sun, 26 Feb 2023 at 16:16, Jon Ribbens via Python-list > > wrote: > >> On 2023-02-25, Paul Rubin wrote: > >> > The GIL is an evil thing, but it has been around for so long that most

Re: Is there a more efficient threading lock?

> And yet, it appears that *something* changed between Python 2 and Python 3 such that it *is* atomic: I haven't looked, but something to check in the source is opcode prediction. It's possible that after the BINARY_OP executes, opcode prediction jumps straight to the STORE_FAST opcode, avoiding

Re: Is there a more efficient threading lock?

T_CHECK 0 (x) > 4 LOAD_CONST 1 (1) > 6 BINARY_OP 13 (+=) > 10 STORE_FAST 0 (x) > 12 LOAD_CONST 0 (None) > 14 RETURN_VALUE >>>> > > The exact sa

Re: Is there a more efficient threading lock?

On 2023-02-26, Barry Scott wrote: > On 25/02/2023 23:45, Jon Ribbens via Python-list wrote: >> I think it is the case that x += 1 is atomic but foo.x += 1 is not. > > No that is not true, and has never been true. > >:>>> def x(a): >:...    a += 1 >:... >:>>> >:>>> dis.dis(x) >  1   0

Re: Is there a more efficient threading lock?

On 25/02/2023 23:45, Jon Ribbens via Python-list wrote: I think it is the case that x += 1 is atomic but foo.x += 1 is not. No that is not true, and has never been true. :>>> def x(a): :...    a += 1 :... :>>> :>>> dis.dis(x)  1   0 RESUME   0  2   2

Re: Is there a more efficient threading lock?

e GIL during computation. Here's a script that's quite capable of saturating my CPU entirely - in fact, typing this email is glitchy due to lack of resources: import threading import bcrypt results = [0, 0] def thrd(): for _ in range(10): ok = bcrypt.checkpw(b"password"

Re: Is there a more efficient threading lock?

the __iadd__ method both mutates and returns something other than self, which is quite unusual. (Most incrementing is done by either constructing a new object to return, or mutating the existing one, but not a hybrid.) Consider this: import threading d = {0:0, 1:0, 2:0, 3:0} def thrd(): for _

Re: Is there a more efficient threading lock?

y one thread will be running at any moment regardless of CPU count. Common wisdom is that Python threading works well for I/O bound systems, where each thread spends most of its time waiting for some I/O operation to complete -- thereby allowing the OS to schedule other threads. For CP

Re: Is there a more efficient threading lock?

On 2023-02-25, Paul Rubin wrote: > Jon Ribbens writes: >>> 1) you generally want to use RLock rather than Lock >> Why? > > So that a thread that tries to acquire it twice doesn't block itself, > etc. Look at the threading lib docs for more info. Yes, I know what the

Re: Is there a more efficient threading lock?

On 2023-02-25, Paul Rubin wrote: > Skip Montanaro writes: >> from threading import Lock > > 1) you generally want to use RLock rather than Lock Why? > 2) I have generally felt that using locks at the app level at all is an > antipattern. The main way I've stayed sane in

Re: Is there a more efficient threading lock?

Re sqlite and threads. The C API can be compiled to be thread safe from my Reading if the sqlite docs. What I have not checked is how python’s bundled sqlite is compiled. There are claims python’s sqlite is not thread safe. Barry -- https://mail.python.org/mailman/listinfo/python-list

Re: Is there a more efficient threading lock?

On 2/25/2023 4:41 PM, Skip Montanaro wrote: Thanks for the responses. Peter wrote: Which OS is this? MacOS Ventura 13.1, M1 MacBook Pro (eight cores). Thomas wrote: > I'm no expert on locks, but you don't usually want to keep a lock while > some long-running computation goes on.  You

Re: Is there a more efficient threading lock?

“I'm no expert on locks, but you don't usually want to keep a lock while some long-running computation goes on. You want the computation to be done by a separate thread, put its results somewhere, and then notify the choreographing thread that the result is ready.” Maybe. There are so many

Re: Is there a more efficient threading lock?

Thanks for the responses. Peter wrote: > Which OS is this? MacOS Ventura 13.1, M1 MacBook Pro (eight cores). Thomas wrote: > I'm no expert on locks, but you don't usually want to keep a lock while > some long-running computation goes on. You want the computation to be > done by a separate

Re: Is there a more efficient threading lock?

On 2023-02-25 09:52:15 -0600, Skip Montanaro wrote: > BLOB_LOCK = Lock() > > def get_terms(text): > with BLOB_LOCK: > phrases = TextBlob(text, np_extractor=EXTRACTOR).noun_phrases > for phrase in phrases: > yield phrase > > When I monitor the application using py-spy,

Re: Is there a more efficient threading lock?

On 2/25/2023 10:52 AM, Skip Montanaro wrote: I have a multi-threaded program which calls out to a non-thread-safe library (not mine) in a couple places. I guard against multiple threads executing code there using threading.Lock. The code is straightforward: from threading import Lock

Re: Is there a more efficient threading lock?

On 2023-02-25 09:52:15 -0600, Skip Montanaro wrote: > I have a multi-threaded program which calls out to a non-thread-safe > library (not mine) in a couple places. I guard against multiple > threads executing code there using threading.Lock. The code is > straightforward: > &

Is there a more efficient threading lock?

I have a multi-threaded program which calls out to a non-thread-safe library (not mine) in a couple places. I guard against multiple threads executing code there using threading.Lock. The code is straightforward: from threading import Lock # Something in textblob and/or nltk doesn't play nice

Re: Recommendations in terms of threading, multi-threading and/or asynchronous processes/programming? - Sent Mail - Mozilla Thunderbird

ably don't need multi-processing just to utilize all your cores. On the other hand you have some nicely separated task which can be parallelized, so multi-threading should help (async probably would work just as well or as badly as multi-threading but I find that harder to understand so I would discard i

Re: Recommendations in terms of threading, multi-threading and/or asynchronous processes/programming? - Sent Mail - Mozilla Thunderbird

processing large chunks of e-mail messages - either send a message to the thread, or set a global variable to tell it to end the run after the current process item has finished off, just in case. So, I think that for now, threading is probably the simplest to look into. Later on, was also considering

Re: Recommendations in terms of threading, multi-threading and/or asynchronous processes/programming? - Sent Mail - Mozilla Thunderbird

On Sat, 7 Jan 2023 at 04:54, jacob kruger wrote: > > I am just trying to make up my mind with regards to what I should look > into working with/making use of in terms of what have put in subject line? > > > As in, if want to be able to trigger multiple/various threads/processes > to run in the

Re: Recommendations in terms of threading, multi-threading and/or asynchronous processes/programming? - Sent Mail - Mozilla Thunderbird

On 2023-01-06 10:18:24 +0200, jacob kruger wrote: > I am just trying to make up my mind with regards to what I should look into > working with/making use of in terms of what have put in subject line? > > > As in, if want to be able to trigger multiple/various threads/processes to > run in the

Recommendations in terms of threading, multi-threading and/or asynchronous processes/programming? - Sent Mail - Mozilla Thunderbird

interface, or via global variables, but, possibly while processing other forms of user interaction via the normal/main process, what would be recommended? As in, for example, the following page mentions some possibilities, like threading, asyncio, etc., but, without going into too much detail

[issue210861] time.sleep() and threading (PR#307)

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue500447] native win32 threading primitives

Change by admin : -- github: None -> 35878 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue460269] Improve threading on Solaris platform.

Change by admin : -- github: None -> 35145 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue443614] enhancement for threading._Semaphore

Change by admin : -- github: None -> 34809 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue428326] Timer class for threading

Change by admin : -- github: None -> 34555 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue440464] Threading Program Crashes Python 2.1

Change by admin : -- github: None -> 34733 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue233665] Race condition in threading (Conditions)

Change by admin : -- github: None -> 33993 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue403155] avoid warning using modules thread and threading

Change by admin : -- github: None -> 33681 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue222986] threading not ok with GNU pth - bis

Change by admin : -- github: None -> 33497 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue222985] threading not ok with GNU pth

Change by admin : -- github: None -> 33496 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401226] make threading fork-safe

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue222986] threading not ok with GNU pth - bis

Change by admin : -- github: None -> 33497 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue222985] threading not ok with GNU pth

Change by admin : -- github: None -> 33496 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue210861] time.sleep() and threading (PR#307)

Change by admin : -- github: None -> 32859 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401226] make threading fork-safe

Change by admin : -- github: None -> 32958 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

Re: Threading question .. am I doing this right?

Chris Angelico wrote: > I'm still curious as to the workload (requests per second), as it might still > be worth going for the feeder model. But if your current system works, then > it may be simplest to debug that rather than change. It is by all accounts a low-traffic situation, maybe one

Re: Threading question .. am I doing this right?

On Sat, 26 Feb 2022 at 05:16, Robert Latest via Python-list wrote: > > Chris Angelico wrote: > > Depending on your database, this might be counter-productive. A > > PostgreSQL database running on localhost, for instance, has its own > > caching, and data transfers between two apps running on the

Re: Threading question .. am I doing this right?

Greg Ewing wrote: > * If more than one thread calls get_data() during the initial > cache filling, it looks like only one of them will wait for > the thread -- the others will skip waiting altogether and > immediately return None. Right. But that needs to be dealt with somehow. No data is no

Re: Threading question .. am I doing this right?

Chris Angelico wrote: > Depending on your database, this might be counter-productive. A > PostgreSQL database running on localhost, for instance, has its own > caching, and data transfers between two apps running on the same > computer can be pretty fast. The complexity you add in order to do >

Re: Threading question .. am I doing this right?

On 25/02/22 1:08 am, Robert Latest wrote: My question is: Is this a solid approach? Am I forgetting something? I can see a few of problems: * If more than one thread calls get_data() during the initial cache filling, it looks like only one of them will wait for the thread -- the others will

Re: Threading question .. am I doing this right?

On Fri, 25 Feb 2022 at 06:54, Robert Latest via Python-list wrote: > > I have a multi-threaded application (a web service) where several threads need > data from an external database. That data is quite a lot, but it is almost > always the same. Between incoming requests, timestamped records get

Threading question .. am I doing this right?

that gets only "topped up" with the most recent records on each request: from threading import Lock, Thread class MyCache(): def __init__(self): self.cache = None self.cache_lock = Lock() def _update(self): n

[issue41962] Make threading._register_atexit public?

Ben Darnell added the comment: > To be clear, by "cancel" you are not talking about Future.cancel(). Rather, > your handler causes all running tasks to finish (by sending a special message > on the socket corresponding to each running task). Is that right? Correct. My tasks here are calls

[issue41962] Make threading._register_atexit public?

utdown() That would require a little refactoring to make it work. However, the change is simpler if each executor has its own atexit handler: class ThreadPoolExecutor(_base.Executor): def __init__(self, ...): ... threading._register_atexit(self._atexit()) def _atexi

[issue41962] Make threading._register_atexit public?

eue * ThreadPoolExecutor.submit(task) -> thread (worker) * thread -> worker -> ( queue -> work item -> task ) Observations:: * the worker loop exits if the next item in the queue is None (and the executor is shutting down) Now lets look more closely at the atex

[issue41962] Make threading._register_atexit public?

Eric Snow added the comment: > I'm running some long-running (possibly infinite) tasks in the thread pool, > and I cancel them in an `atexit` callback Alternately, perhaps ThreadPoolExecutor isn't the right fit here, as implied by the route you ended up going. It seems like it's not

[issue41962] Make threading._register_atexit public?

Eric Snow added the comment: > I'm running some long-running (possibly infinite) tasks in the thread pool, > and I cancel them in an `atexit` callback To be clear, by "cancel" you are not talking about Future.cancel(). Rather, your handler causes all running tasks to finish (by sending a

[issue41962] Make threading._register_atexit public?

Simon Arlott added the comment: Another way to do this is to call threading.main_thread().join() in another thread and do the shutdown cleanup when it returns. The main thread is stopped at shutdown just before the threading._threading_atexits are called. -- nosy: +sa

Re: threading and multiprocessing deadlock

Johannes Bauer wrote at 2021-12-6 00:50 +0100: >I'm a bit confused. In my scenario I a mixing threading with >multiprocessing. Threading by itself would be nice, but for GIL reasons >I need both, unfortunately. I've encountered a weird situation in which >multiprocessing Proce

Re: threading and multiprocessing deadlock

> On 5 Dec 2021, at 23:50, Johannes Bauer wrote: > > Hi there, > > I'm a bit confused. In my scenario I a mixing threading with > multiprocessing. Threading by itself would be nice, but for GIL reasons > I need both, unfortunately. I've encountered a wei

Re: threading and multiprocessing deadlock

Am 06.12.21 um 13:56 schrieb Martin Di Paola: > Hi!, in short your code should work. > > I think that the join-joined problem is just an interpretation problem. > > In pseudo code the background_thread function does: > > def background_thread() >   # bla >   print("join?") >   # bla >  

Re: threading and multiprocessing deadlock

the threads that you spawned (background_thread functions). I hope that this can guide you to fix or at least narrow the issue. Thanks, Martin. On Mon, Dec 06, 2021 at 12:50:11AM +0100, Johannes Bauer wrote: Hi there, I'm a bit confused. In my scenario I a mixing threading with multiprocessin

threading and multiprocessing deadlock

Hi there, I'm a bit confused. In my scenario I a mixing threading with multiprocessing. Threading by itself would be nice, but for GIL reasons I need both, unfortunately. I've encountered a weird situation in which multiprocessing Process()es which are started in a new thread don't actually start

[issue45311] Threading Semaphore and BoundedSemaphore release method implementation improvement

Serhiy Storchaka added the comment: This code was added in bpo-10978. Raymond, what are your thoughts? -- nosy: +rhettinger versions: +Python 3.11 -Python 3.9 ___ Python tracker

[issue45311] Threading Semaphore and BoundedSemaphore release method implementation improvement

Besart Dollma added the comment: This is another illogical behaviour, if I am trying to release 5 threads, and I fail the releasing the first one, why should I try the first one 5 times? -- ___ Python tracker

[issue45311] Threading Semaphore and BoundedSemaphore release method implementation improvement

Change by Ken Jin : -- nosy: +pitrou, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45311] Threading Semaphore and BoundedSemaphore release method implementation improvement

Change by Andrei Kulakov : -- nosy: +kj ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45311] Threading Semaphore and BoundedSemaphore release method implementation improvement

Andrei Kulakov added the comment: Besart: with the current code, if there's a valueError when releasing a thread, it will be retried again n times, with your change, n waiting threads will be released, even if some of them fail with ValueError. I don't know enough about threading module

[issue35747] Python threading event wait influenced by date change

Change by STINNER Victor : -- superseder: Use the monotonic clock for thread conditions on POSIX platforms -> NewGIL should use CLOCK_MONOTONIC if possible. ___ Python tracker

[issue1596321] KeyError at exit after 'import threading' in other thread

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue24391] Better repr for threading objects

Serhiy Storchaka added the comment: New changeset eed32df5b6b989caf125d829301546db58b529dd by Serhiy Storchaka in branch 'main': bpo-24391: Better reprs for threading objects. (GH-20534) https://github.com/python/cpython/commit/eed32df5b6b989caf125d829301546db58b529dd

[issue45311] Threading Semaphore and BoundedSemaphore release method implementation improvement

) messages: 402779 nosy: besi7dollma priority: normal severity: normal status: open title: Threading Semaphore and BoundedSemaphore release method implementation improvement type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.

[issue1596321] KeyError at exit after 'import threading' in other thread

STINNER Victor added the comment: Better late than never. I only took 15 years to fix this old bug :-D -- versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.2 ___ Python tracker

[issue1596321] KeyError at exit after 'import threading' in other thread

STINNER Victor added the comment: New changeset 94d19f606fa18a1c4d2faca1caf2f470a8ce6d46 by Victor Stinner in branch '3.9': bpo-1596321: Fix threading._shutdown() for the main thread (GH-28549) (GH-28589) https://github.com/python/cpython/commit/94d19f606fa18a1c4d2faca1caf2f470a8ce6d46

[issue1596321] KeyError at exit after 'import threading' in other thread

miss-islington added the comment: New changeset 38c67738c64304928c68d5c2bd78bbb01d979b94 by Miss Islington (bot) in branch '3.10': bpo-1596321: Fix threading._shutdown() for the main thread (GH-28549) https://github.com/python/cpython/commit/38c67738c64304928c68d5c2bd78bbb01d979b94

[issue1596321] KeyError at exit after 'import threading' in other thread

Change by STINNER Victor : -- pull_requests: +26971 pull_request: https://github.com/python/cpython/pull/28589 ___ Python tracker ___

[issue1596321] KeyError at exit after 'import threading' in other thread

Change by miss-islington : -- nosy: +miss-islington nosy_count: 15.0 -> 16.0 pull_requests: +26970 pull_request: https://github.com/python/cpython/pull/28588 ___ Python tracker

[issue1596321] KeyError at exit after 'import threading' in other thread

STINNER Victor added the comment: New changeset 95d31370829b7d729667588e0a9943217401ea5b by Victor Stinner in branch 'main': bpo-1596321: Fix threading._shutdown() for the main thread (GH-28549) https://github.com/python/cpython/commit/95d31370829b7d729667588e0a9943217401ea5b

[issue24391] Better repr for threading objects

Change by Serhiy Storchaka : -- versions: +Python 3.11 -Python 3.5, Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue24391] Better repr for threading objects

Serhiy Storchaka added the comment: In the last version of PR 20534, the reprs will be similar to proposed by Larry in msg244958, except that a colon is used to separate an address from status, and keyword names are used for values. It is closer to existing reprs, I'm going to

[issue1736792] dict reentrant/threading request

STINNER Victor added the comment: > As I first mentioned in my post[1] on comp.lang.python, it seems possible to > modify a dict while a lookup is ongoing, without causing the lookup to > restart. That's a bad practice. Python dict raises an exception in some cases: RuntimeError("dict

[issue40699] Memory leak in threading library with Python 3.6-3.8

STINNER Victor added the comment: I fail to reproduce the leak using attached script. I close the issue. I get constant memory usage on Linux with the main branch of Python (future 3.11): (...) VmRSS: 11344 kB VmRSS: 11344 kB VmRSS: 11344 kB VmRSS: 11344 kB VmRSS: 11344

[issue43050] threading timer memory leak

STINNER Victor added the comment: I cannot reproduce the issue. IMO it has been fixed. Moreover, you must join timers using timer.join(): a timer remains a thread. Code: --- import os import threading os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") # warmup for n in range(10):

[issue1596321] KeyError at exit after 'import threading' in other thread

STINNER Victor added the comment: I proposed PR 28549 to fix this very old threading issue. A C extension can spawn threads without using the threading module and then then run Python code which imports the threading module. In this case, threading._main_thread is the thread which imported

[issue1596321] KeyError at exit after 'import threading' in other thread

Change by STINNER Victor : -- keywords: +patch nosy: +vstinner nosy_count: 14.0 -> 15.0 pull_requests: +26932 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/28549 ___ Python tracker

[issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

Change by Victor Vorobev : -- nosy: +victorvorobev nosy_count: 15.0 -> 16.0 pull_requests: +26659 pull_request: https://github.com/python/cpython/pull/28239 ___ Python tracker

[issue1596321] KeyError at exit after 'import threading' in other thread

Irit Katriel added the comment: The output is different now. I update the script for python 3: - import _thread as thread import time def start(): print("Secondary thread ID:", thread.get_ident()) import threading p

[issue44871] Threading memory leak

Change by Benjamin Peterson : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Memory leak/high usage on copy in different thread ___ Python tracker

[issue44871] Threading memory leak

priority: normal severity: normal status: open title: Threading memory leak type: performance versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file50206/threading_leak.py ___ Python tracker

[issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

Change by Roundup Robot : -- pull_requests: +25992 pull_request: https://github.com/python/cpython/pull/27473 ___ Python tracker ___

Re: Python threading comparison

On Wed, Jun 23, 2021 at 5:34 AM Dan Stromberg wrote: > > I put together a little python runtime comparison, with an embarallel, > cpu-heavy threading microbenchmark. > > It turns out that the performance-oriented Python implementations, Pypy3 > and Nuitka3, are both

Python threading comparison

I put together a little python runtime comparison, with an embarallel, cpu-heavy threading microbenchmark. It turns out that the performance-oriented Python implementations, Pypy3 and Nuitka3, are both poor at threading, as is CPython of course. On the plus side for CPython, adding cpu-heavy

[issue44430] [sqlite3] refactor threading tests

Pablo Galindo Salgado added the comment: New changeset 5f0fc30de46d41dccf04096df12664fc0a684ca2 by Erlend Egeberg Aasland in branch 'main': bpo-44430: Refactor `sqlite3` threading tests (GH-26748) https://github.com/python/cpython/commit/5f0fc30de46d41dccf04096df12664fc0a684ca2

  1   2   3   4   5   6   7   8   9   10   >