The essence of what. I work on Dzhanga. I do not know for sure, but I guess that there is some kind of main thread that comes from the process launched by the server, which processes the user's request, and then immediately stops its work.

In this thread, you need to start another stream that should work out the simplest function (for example, print) after some time, for example, in a minute.

I understand that the best choice for me is Timer in the threading module.

But, if the stream is not a daemon, then the parent stream will hang for a minute along with the child, so how can it not stop its work, and will eat resources? I understand correctly? That is, do I need to set the daemon property = True?

What, programmatically and by properties, does a regular stream differ from a daemon? What data does it store? I would also like to know. When should each type be used?

    2 answers 2

    On shutdown, the __main__ stream

    all daemon threads will be forcibly terminated

    all не daemon threads will continue their work

     import threading, sys def printer(): print('threading print') def fn(): print('start fn') threading.Timer(1, printer).start() print('stop fn')

    daemon=False

     if __name__ == '__main__': sys.exit(threading.Thread(target=fn, daemon=False).start()) # главный поток должен бы 'завершится' тут # но тк fn-поток не Daemon, главный будет ждать завершения выполнения fn()

    out:

     start fn stop fn threading print

    daemon=True

     if __name__ == '__main__': sys.exit(threading.Thread(target=fn, daemon=True).start()) # главный поток завершится тут. # но тк fn-поток Daemon, выполнение fn() прервется

    out:

     start fn

    from threading.py

     @property def daemon(self): """A boolean value indicating whether this thread is a daemon thread. This must be set before start() is called, otherwise RuntimeError is raised. Its initial value is inherited from the creating thread; the main thread is not a daemon thread and therefore all threads created in the main thread default to daemon = False. The entire Python program exits when no alive non-daemon threads are left. """
    • I read three times, so I did not understand what question it is the answer to. - Mr Fix
    • To the one in your example there are 3 threads: There is a main stream [1]. There is a parent thread [2] (which processes the user's request, and then immediately stops its work). There is a daemon print stream [3]. The thread [3] will not hang for a minute along with the stream- [2] tk daemon determines only the behavior of the stream [3], after the thread has finished [1], and the stream [2] can complete execution before the print from the stream [3] begins - vadim vaduxa
    • You have painted everything well. Thank you very much for your time. But your answer does not answer the question. - Mr Fix
    • Well, under the number [1] is still a process, not a stream. - Mr Fix
    • Gave a reward. Apparently no one understands the question. - Mr Fix

    I do not know for sure, but I guess that there is some kind of main thread that comes from the process launched by the server, which processes the user's request, and then immediately stops its work.

    No, django-project scripts are loaded by the WSGI server into memory at startup and remain there until the end of its work. Excluding nuances, like restarting WSGI server processes when certain events occur.

    The WSGI server, when it receives http requests, calls WSGIHandler , which in turn calls the appropriate views , be it a function or a CBV method. The submission should respond to the request as quickly as possible and complete the work. Therefore, any long-term tasks should be shifted to background services.

    I understand that the best choice for me is Timer in the threading module.

    No, the best choice for you is Celery .

    Django is not just non-safe, it is specifically designed to be single-tasked. Any attempts to use threads or asynchrony in it is the path to inevitable and subtle errors.

    And Celery is the de facto standard for background and periodic tasks in django development. The available alternatives in the form of uWSGI Spooler or Huey can only boast of greater ease of setup, but have significantly fewer features and tiny communities.