Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to avoid duplicate threads in debug mode #5436

Closed
signag opened this issue Mar 11, 2024 · 0 comments
Closed

How to avoid duplicate threads in debug mode #5436

signag opened this issue Mar 11, 2024 · 0 comments

Comments

@signag
Copy link

signag commented Mar 11, 2024

Issue Description

I have a similar issue as #5307 and I also understand the arguments related to threads in web applications.

In my case of a web server for controlling Raspberry Pi cameras raspiCamSrv, there are several threads under control of the web app, like live stream, video recording, etc.
These threads use the Picamera2 library which starts its own threads.

This is normally not an issue because these threads are started by users from the Web UI after the Flask server has started.

Now, I have added a motion capture feature, which is also running in an own thread and users want this feature to be automatically started with the server, for example after the device has been rebooted.

Currently, I start this thread in the app factory create_app().
And, as in #5307, the thread is started again when I start Flask with the --debug option.

I do not seem to have the possibility from my own code to detect whether these threads are already active.
The classes from which these threads are started and which hold their references, seem to be initialized again, although they are singletons.

Question

I am not considering this as a bug.

My question is whether there is a possibility in create_app(), to know that the app is being recreated on behalf of the autoloader.

Environment:

  • Python version: 3.11.2
  • Flask version: 3.0.0
  • Wekzeug version: 3.0.1
@pallets pallets locked and limited conversation to collaborators Mar 11, 2024
@davidism davidism converted this issue into discussion #5437 Mar 11, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant