Django 애플리케이션을 개발하는 과정에서 개발자 모드를 사용하여 서비스를 시작하는 것이 특히 편리합니다. 서비스를 실행하려면 pythonmanage.py runserver만 있으면 되며, 별도의 작업이 필요 없이 매우 사용자 친화적인 자동 다시 로드 메커니즘을 제공합니다. 프로그램을 수동으로 다시 시작하면 코드를 수정하고 피드백을 볼 수 있습니다. 처음 접했을 때 이 기능이 좀 더 사용자 친화적이라는 느낌을 받았고, 딱히 첨단 기술이라고는 생각하지 않았습니다. 나중에 시간이 나면 이 자동 재장전을 구현하면 어떨까 하는 생각을 하게 되었는데, 오랫동안 생각해봐도 알 수 없는 부분이 늘 있었습니다. 내 첫 반응은 야망이 너무 많고 기술이 너무 부족하다는 것 같았습니다. 그래서 나는 Django가 자동 재로드를 구현하는 방법을 연구하는 데 시간을 보냈고 모든 단계에 대한 소스 코드를 살펴보았고 아무것도 당연하게 여기지 않았습니다:
1. 주제에 들어가기 전에 실제로 runserver 명령이 어떻게 실행되는지에 대한 말도 안되는 긴 단락이 있습니다. 주제와 관련이 거의 없으므로 간략하게 언급하겠습니다:
명령줄에 python Manage.py runserver를 입력한 후 , Django는 runserver 명령의 실행 모듈을 찾고 마지막으로
djangocontribstaticfilesmanagementcommandsrunserver.py 모듈에 속합니다:
#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."
그리고 이 명령의 실행 기능은 여기에 있습니다:
#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)
use_reloader에 대한 판단은 이렇습니다. 시작 명령에 --noreload를 추가하지 않으면 프로그램은 autoreload.main 함수로 이동하고, 이를 추가하면 self.inner_run으로 이동하여 애플리케이션을 직접 시작합니다.
실제로 autoreload.main의 매개변수에서 self.inner_run의 일부 캡슐화가 필요하다는 것을 알 수 있습니다. 자동 다시 로드의 메커니즘은 이러한 캡슐화에 있습니다.
PS: 소스 코드를 살펴보면 Django의 명령 모드가 여전히 매우 아름답게 구현되어 있고 배울 가치가 있다는 것을 알았습니다.
2. 자동 재로드 모듈. 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)여기서 jpython과 다른 Python을 구별합니다. 먼저 jpython을 무시합니다. check_errors는 main_func의 오류를 처리하고 먼저 무시합니다. 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 < 0:
os.kill(os.getpid(), -exit_code)
else:
sys.exit(exit_code)
except KeyboardInterrupt:
pass처음 여기에 왔을 때 환경 변수의 RUN_MAIN 변수가 "true"가 아니었고 거기에도 없었으므로 다른 방법으로 가서 restart_with_reloader:
#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
여기서는 먼저 while 루프를 시작하고 내부적으로 RUN_MAIN을 "true"로 변경한 다음 os.spawnve 메서드를 사용하여 하위 프로세스(하위 프로세스)를 엽니다.
_spawnvef(mode, file, args, env, execve)
사실 명령줄을 다시 조정하고 pythonmanage.py runserver를 다시 실행하세요.
다음으로, restart_with_reloader의 while 루프를 살펴보세요. while 루프가 종료되는 유일한 조건은exit_code!=3입니다. 하위 프로세스가 종료되지 않으면 os.spawnve 단계에서 중지됩니다. 하위 프로세스가 종료되고 종료 코드가 3이 아니면 while이 종료되며 루프가 계속되고 하위 프로세스가 종료됩니다. 다시 만들어졌습니다. 이 논리에서 우리는 자동 다시 로드의 메커니즘을 추측할 수 있습니다. 현재 프로세스(주 프로세스)는 실제로 아무 작업도 수행하지 않지만 자식 프로세스의 실행 상태를 모니터링합니다. 자식 프로세스가 exit_code=3으로 종료되는 경우입니다. (파일이 수정되면 감지로 인해 발생해야 함) 하위 프로세스를 다시 시작하면 하위 프로세스가 exit_code!=3으로 종료되면 새 코드가 자연스럽게 적용되며 기본 프로세스도 종료됩니다. 전체 Django 프로그램이 다운될 것입니다. 이는 단지 추측일 뿐이며, 아래에서 확인하겠습니다.
3. 하위 프로세스. 실제로 위의 질문이 있습니다. 다시 시작했는데 왜 하위 프로세스가 다른 하위 프로세스를 생성하지 않습니까? 그 이유는 메인 프로세스에서 RUN_MAIN 환경 변수가 true로 변경되기 때문입니다. 하위 프로세스가 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 < 0:
os.kill(os.getpid(), -exit_code)
else:
sys.exit(exit_code)
except KeyboardInterrupt:
pass조건이 충족되면 로직이 메인 프로세스와 다릅니다. 프로세스. 여기서 먼저 스레드를 열고 위의 Command.inner_run인 main_func를 실행합니다. 여기 스레드 모듈은 다음과 같이 가져옵니다.
#django\utils\autoreload.py:from django.utils.six.moves import _thread as thread
여기서 6개 모듈의 역할은 다양한 Python 버전과 호환되는 것입니다.
[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.
그래서 프로그램이 원하는 경우 python2 및 python3에서 실행 가능 Running, Lupine 및 six는 중요한 도구입니다. 그런 다음 시간을 내어 6개를 살펴보고 표시해 보세요.
그런 다음 reloader_thread를 엽니다.
=== change ==3) change ==1)
ensure_echo_on() 사실 아직 이해하지 못했습니다. 유닉스 계열 시스템 파일 처리용인 것 같으니 먼저 건너뛰세요.
USE_INOTIFY도 시스템 파일 작업과 관련된 변수 inotify 사용 가능 여부에 따라 파일 변경을 감지하는 방법을 선택합니다.
While 루프에서는 1초마다 파일 상태를 확인합니다. 일반 파일에 변경 사항이 있으면 프로세스는 종료 코드 3으로 종료됩니다. 메인 프로세스에서 종료 코드가 3인 것을 확인하면 하위 프로세스가 다시 시작됩니다. 프로세스. . . . 이는 위와 연결됩니다. 일반적인 파일 변경이 아니라 I18N_MODIFIED(.mo 접미사, 바이너리 라이브러리 파일 등을 사용한 파일 변경)인 경우에는 다음 번에 로드된 라이브러리 캐시를 지우는 것을 의미할 수 있습니다. .
위는 자동 재장전 메커니즘의 프로세스입니다. 다양한 운영 체제에서 파일 변경을 감지하는 등 특별히 명확하지 않은 일부 세부 사항이 있지만 이는 매우 세부적인 사항이며 주요 프로세스와 관련이 없습니다. 이 글을 읽은 후, 나는 자동 재장전 메커니즘을 디자인하라는 요청을 받으면 어떻게 할 것인지 다시 스스로에게 물었습니다. 이제 내 대답은: djangoutilsautoreload.py 파일을 직접 사용하는 것입니다. 실제로 이것은 매우 독립적인 모듈이며 매우 다재다능합니다. 범용 자동 다시 로드 솔루션으로 사용할 수도 있습니다.
위 내용은 Django 개발자 모드에서 자동 다시 로드는 어떻게 구현되나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
