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

the thing causing the cited exception "threads can only be started once". Your setup of the button with the action defined as: Thread().start creates a _single_ new Thread _when you define the button_, and makes hte button callback try to start it. On the second and followin

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 exception "th

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

On 2023-01-10 14:57, Abhay Singh wrote: Here is the entire code snippet of the same. Please help def change_flag(top_frame, bottom_frame, button1, button2, button3, button4, controller): global counter, canvas, my_image, chosen, flag, directory canvas.delete('all') button5['state'] =

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

Here is the entire code snippet of the same. Please help def change_flag(top_frame, bottom_frame, button1, button2, button3, button4, controller): global counter, canvas, my_image, chosen, flag, directory canvas.delete('all') button5['state'] = DISABLED counter += 1 chosen, options_text =

[issue228210] Threads using same stream blow up (Windows)

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

[issue210694] PRIVATE: Threads and readline (PR#120)

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

[issue210650] [HP-UX] python with-threads core-dumps (PR#342)

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

[issue443783] Cygwin32 builds threads, but they hang

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

[issue229995] segfaults on AIX if configured with threads

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

[issue539990] Framework.mainloop() - multiple threads

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

[issue401936] Auto-detect DEC threads (which need "-threads" argument)

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

[issue215076] threads of __del__

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

[issue502236] Asynchronous exceptions between threads

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

[issue504224] add plan9 threads include to thread.c

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

[issue210706] gcc error msg, 1.5.2, Slackware + threads (PR#44)

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

[issue210703] select with dec-threads core dumps (PR#35)

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

[issue479981] test_socket fails when compiled with threads (HP-UX)

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

[issue478006] memory leaks in Modules & threads

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

[issue221963] IDLE hangs on Threads

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

[issue221115] Kill threads from main thread

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

[issue215076] threads of __del__

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

[issue420720] Starting many threads causes core dump

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

[issue416696] --with-threads fail for 2.1c2 on HPUX 11

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

[issue410608] popen with threads

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

[issue231540] threads and profiler don't work together

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

[issue231189] Crash when Python Re-Initialized with Daemon Threads

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

[issue221963] IDLE hangs on Threads

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

[issue221327] threads within an embedded python interpreter

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

[issue221115] Kill threads from main thread

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

[issue401606] threads and __del__

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

[issue210665] Compiling python on hpux 11.00 with threads (PR#360)

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

[issue210646] threads (PR#333)

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

[issue210611] Signal processing bug (Linux threads, readline, whatever else) (PR#196)

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

[issue221327] threads within an embedded python interpreter

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

[issue401936] Auto-detect DEC threads (which need "-threads" argument)

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

[issue401606] threads and __del__

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

[issue210706] gcc error msg, 1.5.2, Slackware + threads (PR#44)

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

[issue210694] PRIVATE: Threads and readline (PR#120)

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

[issue210665] Compiling python on hpux 11.00 with threads (PR#360)

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

[issue210703] select with dec-threads core dumps (PR#35)

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

[issue210650] [HP-UX] python with-threads core-dumps (PR#342)

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

[issue210611] Signal processing bug (Linux threads, readline, whatever else) (PR#196)

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

[issue210646] threads (PR#333)

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

[issue39812] Avoid daemon threads in concurrent.futures

Change by Josh Rosenberg : -- Removed message: https://bugs.python.org/msg416876 ___ Python tracker ___ ___ Python-bugs-list

[issue39812] Avoid daemon threads in concurrent.futures

Josh Rosenberg added the comment: I think this is causing a regression for code that explicitly desires the ThreadPoolExecutor to go away abruptly when all other non-daemon threads complete (by choosing not to use a with statement, and if shutdown is called, calling it with wait=False

[issue47082] No protection: `import numpy` in two different threads can lead to race-condition

Sebastian Berg added the comment: Thanks, so there should already be a lock in place (sorry, I missed that). But somehow we seem to get around it? Do you know what may cause the locking logic to fail in this case? Recursive imports in NumPy itself? Or Cython using low-level C-API? I.e.

[issue47082] No protection: `import numpy` in two different threads can lead to race-condition

Christian Heimes added the comment: Python used to have a global import lock. The global import lock prevented recursive imports from other threads while the current thread was importing. The import lock was source of issues and dead locks. Antoine replaced it with a fine grained import

[issue7946] Convoy effect with I/O bound threads and New GIL

Sophist added the comment: > https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit 1. The steering committee hasn't given the go ahead for this yet, and we have no idea when such a decision will be made nor whether the decision with be yes or no. 2. Even

[issue7946] Convoy effect with I/O bound threads and New GIL

Guido van Rossum added the comment: Start here: https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit AFAICT the SC hasn't made up their minds about this. -- ___ Python tracker

[issue7946] Convoy effect with I/O bound threads and New GIL

Sophist added the comment: > I think that we should focus our efforts on removing the GIL, now that we > have a feasible solution for doing so without breaking anything Is this really a thing? Something that is definitely happening in a reasonable timescale? Or are there some big

[issue7946] Convoy effect with I/O bound threads and New GIL

version to be merged. This issue would probably hurt Celery since some users use it with a thread pool and it uses a few threads itself but it seems like fixing it is too much effort so if we were to invest a lot of effort, I'd focus on removing the problem entirely. Instead, I suggest we document

[issue7946] Convoy effect with I/O bound threads and New GIL

Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7946] Convoy effect with I/O bound threads and New GIL

Sophist added the comment: Please see also https://github.com/faster-cpython/ideas/discussions/328 for a proposal for a simple (much simpler than BFS) GIL scheduler only allocating the GIL between runable O/S threads waiting to have ownership of the GIL, and using the O/S scheduler

[issue47082] No protection: `import numpy` in two different threads can lead to race-condition

Sebastian Berg added the comment: To add to this: it would seem to me that the side-effects of importing should be guaranteed to only be called once? However, IO or other operations could be part of the import side-effects and release the GIL. So even a simple, pure-Python, package could

[issue47082] No protection: `import numpy` in two different threads can lead to race-condition

New submission from Jens Henrik Goebbert : While using [Xpra](https://github.com/Xpra-org/xpra) we came across a bug which might be a Python or a NumPy issue. Perhaps some of you can help us understanding some internals. Calling `import numpy` at the same time in two different threads

[issue34680] [doc] asyncio event_loop fails when accessed from multiple threads

Change by Irit Katriel : -- keywords: +easy title: asyncio event_loop fails when accessed from multiple threads -> [doc] asyncio event_loop fails when accessed from multiple threads ___ Python tracker <https://bugs.python.org/issu

[issue40811] Allow to create new Event Loops on Threads

Andrew Svetlov added the comment: I suggest closing. The documentation explicitly describes how asyncio works with threads. -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracke

[issue31370] Remove support for threads-less builds

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31370] Remove support for threads-less builds

Change by pmp-p : -- nosy: +pmpp ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

Vidhya added the comment: Thanks Irit for your help. On Thu., Mar. 3, 2022, 10:17 a.m. Irit Katriel, wrote: > > Irit Katriel added the comment: > > Thank you @vidhya. > > -- > resolution: -> fixed > stage: patch review -> resolved > status: open -> closed > >

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

Irit Katriel added the comment: Thank you @vidhya. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

Irit Katriel added the comment: New changeset 09819863a3fb7092ca5cbdfcb722882ebbac806b by Miss Islington (bot) in branch '3.9': bpo-6634: [doc] clarify that sys.exit() does not always exit the interpreter (GH-31639) (GH-31661)

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

miss-islington added the comment: New changeset 9d9dc59d07d51d73e5af7dd506d0da63aa336995 by Miss Islington (bot) in branch '3.10': bpo-6634: [doc] clarify that sys.exit() does not always exit the interpreter (GH-31639)

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

Change by miss-islington : -- nosy: +miss-islington nosy_count: 11.0 -> 12.0 pull_requests: +29778 pull_request: https://github.com/python/cpython/pull/31660 ___ Python tracker

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

Change by miss-islington : -- pull_requests: +29779 pull_request: https://github.com/python/cpython/pull/31661 ___ Python tracker ___

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

Irit Katriel added the comment: New changeset 10117f1d8cb49ce95493555c06050faf636ccee7 by vidhya in branch 'main': bpo-6634: [doc] clarify that sys.exit() does not always exit the interpreter (GH-31639) https://github.com/python/cpython/commit/10117f1d8cb49ce95493555c06050faf636ccee7

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

Vidhya added the comment: Thanks for your comments :). The PR for the same is: https://github.com/python/cpython/pull/31639 -- message_count: 21.0 -> 22.0 pull_requests: +29760 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31639

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

Irit Katriel added the comment: Vidhya, I think the sentence you are suggesting to add would overlap with one which is already there ("Since exit() ultimately “only” raises an exception, it will only exit the process when called from the main thread, and the exception is not intercepted.")

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

Vidhya added the comment: [Entry level contributor seeking guidance] If this is still open, I can work on this. I plan to add the following in sys.exit() and add a reference to thread.exit() at https://docs.python.org/3/library/sys.html#sys.exit: When called from a thread other than the

[issue45339] concurrent.future.ThreadPoolExecutor should parameterize class used for threads

Andrew Svetlov added the comment: I guess if you are asking for initialization and finalization of thread-specific data in a thread pool -- you need exactly these things (or a context manager). A custom thread class reveals too many implementation details. I personally prefer an explicit

[issue34680] asyncio event_loop fails when accessed from multiple threads

Andrew Svetlov added the comment: Please feel free to propose pull request for documentation tuning. -- ___ Python tracker ___ ___

[issue34680] asyncio event_loop fails when accessed from multiple threads

that the loop won't work across threads, like what we ran into at the time, would resolve this. -- ___ Python tracker <https://bugs.python.org/issue34680> ___ ___ Pytho

[issue34680] asyncio event_loop fails when accessed from multiple threads

Irit Katriel added the comment: Perhaps this is just a doc issue - state explicitly that a loop should be used only in one thread, and mention that this is checked in debug mode. -- ___ Python tracker

[issue34680] asyncio event_loop fails when accessed from multiple threads

Andrew Svetlov added the comment: BaseEventLoop has _check_loop() method that is closed in debug mode only. UnixEventLoop doesn't call this method for unix-specific API. Adding the check to add_signal_handler()/remove_signal_handler() doesn't hurt, sure. But it doesn't help as the script is

[issue34680] asyncio event_loop fails when accessed from multiple threads

Irit Katriel added the comment: I think the script does violate the rule: t = threading.Thread(target=do_loop, args=(loop,)) and then do_loop closes the loop that was created in the main thread. -- ___ Python tracker

[issue34680] asyncio event_loop fails when accessed from multiple threads

Andrew Svetlov added the comment: All asyncio loop methods except `loop.call_soon_threadsafe()` should be done from the same thread as been used for the loop creation. Did you violate this rule? -- ___ Python tracker

[issue34680] asyncio event_loop fails when accessed from multiple threads

Change by Irit Katriel : -- title: asyncio event_loop close fails off main thread if signal handler registered -> asyncio event_loop fails when accessed from multiple threads ___ Python tracker <https://bugs.python.org/issu

[issue46493] Add an API to indicate if the process might have multiple threads

New submission from Gregory P. Smith : It'd be handy to have a function to determine if there are multiple threads in the current process or not - at least on POSIXish systems. This would be useful anytime a library is trying to use os.fork(), as fork() is not safe in a multi-threaded

[issue31370] Remove support for threads-less builds

STINNER Victor added the comment: Either reopen the issue or open a new issue. Only people subscribed to this bug are aware of the recent comments. Closed issues are hidden from the bugs home page and from the default search. If you consider that Python must again support thread-less

[issue31370] Remove support for threads-less builds

Brett Cannon added the comment: I am not opening a new discussion; this is just recording this fact here as it has come up in other places on the internet. -- ___ Python tracker

[issue45339] concurrent.future.ThreadPoolExecutor should parameterize class used for threads

Sergei Maertens added the comment: I was looking for some way to be able to add a thread finalizer, a piece of code to be called when the thread pool shuts down and all threads need cleaning up. Glad I came across this issue, since the example of using a Thread subclass with a custom run

[issue46046] I/O bound threads got to no chance to run with small CPU bound threads with new GIL

Ken Jin added the comment: Hi, Thank you for your interest in Python, and especially the GIL. David Beazley opened an issue for his PyCon 2010 GIL talk at https://bugs.python.org/issue7946. You can discuss more on that issue (I suggest first reading through it, there's a really long

[issue31370] Remove support for threads-less builds

Serhiy Storchaka added the comment: Concur with Victor. It is fine to add a link to other discussion in a closed issue, but an issue closed many years ago is not a good place for a new discussion at all. -- ___ Python tracker

[issue31370] Remove support for threads-less builds

STINNER Victor added the comment: > This has unfortunately turned out to be a blocker on getting WASI support as > there's not direct threading support in WebAssembly. This issue is now closed and unrelated to WASI support. Can you please open a new separated issue for it? --

[issue31370] Remove support for threads-less builds

Brett Cannon added the comment: > https://web.dev/webassembly-threads/ suggests otherwise. It actually doesn't as that post isn't for WASI, it's for WASM in the browser (I chose my acronyms carefully ). WASI is like POSIX for WebAssembly, so it's meant for desktop usage and thus no brow

[issue6634] [doc] sys.exit() called from threads other than the main one: undocumented behaviour

of the threading doc. -- keywords: +easy nosy: +iritkatriel title: sys.exit() called from threads other than the main one: undocumented behaviour -> [doc] sys.exit() called from threads other than the main one: undocumented behaviour type: -> behavior versions: +Python 3.10, Python 3.11,

Fwd: I/O bound threads got to no chance to run with small CPU bound threads with new GIL

*Resending this message after subscribing in python-mail-list* -- Forwarded message - From: Souvik Ghosh Date: Sat, Dec 11, 2021 at 5:10 PM Subject: I/O bound threads got to no chance to run with small CPU bound threads with new GIL To: Hello PSF, I'm Souvik Ghosh from India

[issue46046] I/O bound threads got to no chance to run with small CPU bound threads with new GIL

Souvik Ghosh added the comment: Python-ideas link in here:- https://mail.python.org/archives/list/python-id...@python.org/message/A5MX6SQUHP65JC6V5ZFCCHMMJURM4KHB/ -- ___ Python tracker

[issue46046] I/O bound threads got to no chance to run with small CPU bound threads with new GIL

New submission from Souvik Ghosh : According to David Beazley' talk in PyCon'2010 in Atlanta Georgia, he demonstrated about a new GIL with running CPU bound and I/O bound threads together. He said the talk that the threads which are forced to timeout of 5ms, will have the lower priority

[issue31370] Remove support for threads-less builds

Gregory P. Smith added the comment: https://web.dev/webassembly-threads/ suggests otherwise. -- ___ Python tracker <https://bugs.python.org/issue31370> ___ ___

[issue31370] Remove support for threads-less builds

Brett Cannon added the comment: This has unfortunately turned out to be a blocker on getting WASI support as there's not direct threading support in WebAssembly. -- nosy: +brett.cannon ___ Python tracker

[issue7946] Convoy effect with I/O bound threads and New GIL

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45689] Add the ability to give custom names to threads created by ThreadPoolExecutor

Tangellapalli Sai Hanuma Rahul added the comment: Yes, it's true, it's so naive method, Contextvars! may be inside the Future Object? -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue45689] Add the ability to give custom names to threads created by ThreadPoolExecutor

Mark Dickinson added the comment: Sorry Rahul: I'm not the right person to help you push this forward. I'm sympathetic to the problem: I've encountered similar issues in "Real Code", where we needed to associate log outputs generated by worker pool threads with the ac

[issue45689] Add the ability to give custom names to threads created by ThreadPoolExecutor

Tangellapalli Sai Hanuma Rahul added the comment: In summary; == Current Problem: -- ThreadPoolExecutor handles all threads-related activities so the user needs to just submit tasks and set max_workers and other Executor settings if necessary. If ThreadPoolExecutor

[issue45689] Add the ability to give custom names to threads created by ThreadPoolExecutor

Tangellapalli Sai Hanuma Rahul added the comment: There is a new function submit_with_name in _base.Executor that can accept name parameters before args and kwargs, submit can continue to be used as before. submit internally calls submit_with_name with name as None. Calling submit_with_name

[issue45689] Add the ability to give custom names to threads created by ThreadPoolExecutor

Mark Dickinson added the comment: > previously one could write .submit(function_name, *args, **kwargs) > but now one should write > .submit(function_name, name_of_thread, *args, **kwargs) > name_of_thread can be None This approach can't work, I'm afraid: it would be a backwards-incompatible

[issue45689] Add the ability to give custom names to threads created by ThreadPoolExecutor

Change by Alex Waygood : -- title: Custom Name for ThreadPoolExecutor -> Add the ability to give custom names to threads created by ThreadPoolExecutor ___ Python tracker <https://bugs.python.org/issu

[issue44105] tempfile.TemporaryDirectory deleted after sleep in threads

Change by Serhiy Storchaka : -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue45339] concurrent.future.ThreadPoolExecutor should parameterize class used for threads

Erick added the comment: It also occurs to me that even if `concurrent.futures` adopted an alternative Thread class, it would still be preferable to allow for composition in the manner that was originally proposed. -- ___ Python tracker

  1   2   3   4   5   6   7   8   9   10   >