[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?

Eric Snow added the comment: > This means that ThreadPoolExecutor's atexit runs before mine, > and since I never get a chance to cancel my tasks, it deadlocks. (assuming we want to support long-running tasks here) With all the above in mind, there are a few things that may help. The first

[issue41962] Make threading._register_atexit public?

Eric Snow added the comment: FWIW, here's a brain dump about ThreadPoolExecutor and its atexit handler after having looked at the code. First, the relationship between the objects involved: * work item -> Future * work item -> task (e.g. function) * queue -> [work item] * worker ->

[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

[issue41962] Make threading._register_atexit public?

Ben Darnell added the comment: I have resolved my issue here by moving from ThreadPoolExecutor to a plain threading.Thread that I manage by hand (https://github.com/tornadoweb/tornado/commit/15832bc423c33c9280564770046dd6918f3a31b4). Therefore I no longer need this for myself and I leave it

[issue41962] Make threading._register_atexit public?

Ben Darnell added the comment: > IMO, a better practice would be providing those potentially infinite running > tasks a direct method of escape and invoking it before calling > executor.shutdown(), it would be a more reliable approach. Agreed, but the problem is that I'm in a library (so I

[issue41962] Make threading._register_atexit public?

Kyle Stanley added the comment: > I'm dealing with a subtle deadlock involving > concurrent.futures.ThreadPoolExecutor, and my solution that worked in Python > 3.8 broke with 3.9. I'm running some long-running (possibly infinite) tasks > in the thread pool, and I cancel them in an `atexit`

[issue41962] Make threading._register_atexit public?

Change by Irit Katriel : -- components: +Library (Lib) nosy: +aeros, vstinner ___ Python tracker ___ ___ Python-bugs-list mailing

[issue41962] Make threading._register_atexit public?

New submission from Ben Darnell : I'm dealing with a subtle deadlock involving concurrent.futures.ThreadPoolExecutor, and my solution that worked in Python 3.8 broke with 3.9. I'm running some long-running (possibly infinite) tasks in the thread pool, and I cancel them in an `atexit`