How is autoreload implemented in Django developer mode?

In the process of developing Django applications, it is particularly convenient to use the developer mode to start the service. You only need python manage.py runserver to run the service, and it provides a very user-friendly autoreload mechanism, no manual work is required. Restart the program to modify the code and see feedback. When I first came into contact with it, I felt that this function was more user-friendly, and I didn’t think it was a particularly advanced technology. Later, when I had free time, I thought about what I would do if I were to implement this autoreload. After thinking for a long time, I couldn't figure it out. There were always some things that I couldn't figure out. It seemed that my first reaction was that I had too much ambition and too little skill. So I spent some time studying how Django implements autoreload. I looked at the source code for every step and did not allow anything to be taken for granted:

1. Runserver command. Before getting into the topic, there is actually a lot of nonsense about how the runserver command is executed. It has little to do with the topic, so I will briefly mention it:
After typing python manage.py runserver on the command line, Django will look for the runserver command. Execute the module and finally fall on the
django\contrib\staticfiles\management\commands\runserver.py module:

#django\contrib\staticfiles\management\commands\runserver.pyfrom django.core.management.commands.runserver import \
Command as RunserverCommandclass Command(RunserverCommand):
　　help = "Starts a lightweight Web server for development and also serves static files."

And the execution function of this Command is here:

#django\core\management\commands\runserver.pyclass Command(BaseCommand):
　　def run(self, **options):
　　"""　　Runs the server, using the autoreloader if needed
　　"""　　use_reloader = options['use_reloader']

　　if use_reloader:
　　　　autoreload.main(self.inner_run, None, options)
　　else:
　　　　self.inner_run(None, **options)

Here is the judgment about use_reloader. If we do not add --noreload in the startup command, the program will go to the autoreload.main function. If we add it, it will go to self.inner_run and start the application directly.
In fact, it can be seen from the parameters of autoreload.main that it should have some encapsulation of self.inner_run. The mechanism of autoreload is in these encapsulations. Let’s continue to follow.

PS: When looking at the source code, I found that django’s command mode is still very beautifully implemented and is worth learning.

2. autoreload module. Look at autoreload.main():

#django\utils\autoreload.py:def main(main_func, args=None, kwargs=None):
　　if args is None:
　　　　args = ()
　　if kwargs is None:
　　　　kwargs = {}
　　if sys.platform.startswith('java'):
　　　　reloader = jython_reloader
　　else:
　　　　reloader = python_reloader

　　wrapped_main_func = check_errors(main_func)
　　reloader(wrapped_main_func, args, kwargs)

Here is a distinction between jpython and other pythons, ignore jpython first; check_errors is to Perform error handling on main_func and ignore it first. Look at python_reloader:

#django\utils\autoreload.py:def python_reloader(main_func, args, kwargs):
　　if os.environ.get("RUN_MAIN") == "true":
　　　　thread.start_new_thread(main_func, args, kwargs)
　　　　try:
　　　　　　reloader_thread()
　　　　except KeyboardInterrupt:
　　　　　　pass　　else:
　　　　try:
　　　　　　exit_code = restart_with_reloader()
　　　　　　if exit_code <p><br></p><p>When I first came here, the RUN_MAIN variable in the environment variable was not "true", not even there, So go else and look at restart_with_reloader:</p><p class="cnblogs_code"><br></p><pre class="brush:php;toolbar:false">#django\utils\autoreload.py:def restart_with_reloader():    while True:
    　　args = [sys.executable] + ['-W%s' % o for o in sys.warnoptions] + sys.argv
　　　　if sys.platform == "win32":
　　　　　　args = ['"%s"' % arg for arg in args]
　　　　new_environ = os.environ.copy()
　　　　new_environ["RUN_MAIN"] = 'true'　　　　exit_code = os.spawnve(os.P_WAIT, sys.executable, args, new_environ)
　　　　if exit_code != 3:
　　　　　　return exit_code

Here we first start a while loop, and internally change RUN_MAIN to "true". Then use the os.spawnve method to open a subprocess (subprocess) and look at the instructions of os.spawnve:

　　 _spawnvef(mode, file, args, env, execve)

In fact, it is Adjust the command line and run python manage.py runserver again.

Next, look at the while loop in restart_with_reloader. It should be noted that the only condition for the while loop to exit is exit_code!=3. If the child process does not exit, it will stop at the os.spawnve step; if the child process exits, and the exit code is not 3, the while is terminated; if it is 3, the loop continues and the child process is re-created. From this logic, we can guess the mechanism of autoreload: the current process (main process) actually does nothing, but monitors the running status of the child process. The child process is the real thing; if the child process exits with exit_code=3 (it should be due to detection When the file is modified), start the sub-process again, and the new code will naturally take effect; if the sub-process exits with exit_code!=3, the main process will also end, and the entire Django program will be down. This is just a conjecture, and will be verified below.

3. Child process. There is actually a question above. Since it has been restarted, why will the child process not generate another child process? The reason lies in the RUN_MAIN environment variable. It is changed to true in the main process. When the child process reaches the python_reloader function:

#django\utils\autoreload.py:def python_reloader(main_func, args, kwargs):
　　if os.environ.get("RUN_MAIN") == "true":
　　　　thread.start_new_thread(main_func, args, kwargs)
　　　　try:
　　　　　　reloader_thread()
　　　　except KeyboardInterrupt:
　　　　　　pass　　else:
　　　　try:
　　　　　　exit_code = restart_with_reloader()
　　　　　　if exit_code <p><br></p><p>If the condition is met, it will take a different logical branch than the main process. Here, first open a thread and run main_func, which is Command.inner_run above. The thread module here is imported like this: </p><p class="cnblogs_code"><br></p><pre class="brush:php;toolbar:false">#django\utils\autoreload.py:from django.utils.six.moves import _thread as thread

The role of the six module here is to be compatible with various python versions:

[codeblock six]#django\utils\six.pyclass _SixMetaPathImporter(object):"""A meta path importer to import six.moves and its submodules.

This class implements a PEP302 finder and loader. It should be compatible
with Python 2.5 and all existing versions of Python3"""官网说明：# https://pythonhosted.org/six/Six: Python 2 and 3 Compatibility Library
Six provides simple utilities for wrapping over differences between Python 2 and Python 3. It is intended to support codebases that work on both Python 2 and 3 without modification. six consists of only one Python file, so it is painless to copy into a project.

So if the program wants to run on both python2 and python3, and Lupine, six is ​​an important tool. Then take some time to look at six and mark it.

Then open a reloader_thread:

=== change ==3) 　　　　 change ==1)

ensure_echo_on() I haven’t understood it yet, it seems to be for classes For unix system file processing, skip it first;
USE_INOTIFY is also a variable related to system file operations. Select the method to detect file changes based on whether inotify is available.
While loop, check the file status every 1 second. If there is a change in the ordinary file, the process will exit with an exit code of 3. When the main process sees that the exit code is 3, it will restart the child process. . . . This is connected to the above; if it is not an ordinary file change, but I18N_MODIFIED (file change with .mo suffix, binary library file, etc.), then reset_translations, which probably means clearing out the loaded library cache. Reload next time.

The above is the process of autoreload mechanism. There are still some details that are not particularly clear, such as the detection of file changes in different operating systems, but these are very detailed things and do not involve the main process. After reading this, I asked myself again, what would I do if I was asked to design the autoreload mechanism. Now my answer is: use the django\utils\autoreload.py file directly. In fact, this is a very independent module, and it is very versatile. It can be used as a universal autoreload solution. I even wrote it myself.

The above is the detailed content of How is autoreload implemented in Django developer mode?. For more information, please follow other related articles on the PHP Chinese website!