Google App Engine과 유사한 기능인 '지연된 통화'(즉, 요청이 처리되고 이후에 지연된 작업이 처리됨)를 달성하기 위해 약간 실험을 해본 결과 스레드를 생성하는 솔루션이 생겼습니다. 지연된 통화 처리됩니다.wsgi 응용 프로그램에서 스레드를 생성하는 것이 좋습니까?
지금이 방법이 적합한 지 판단하려고합니다.
WSGI 사양에 따라 실제 요청이 처리 된 후 모든 스레드가 다 소모되기 전에 프로세스가 웹 서버에 의해 종료 될 수 있습니까?
(WSGI 응용 프로그램이 파이썬 호출 객체처럼)
FWIW도의 읽기 있습니다. 이는 별도의 스레드가 아니며 실제 요청의 컨텍스트 내에서 발생합니다. 응답이 클라이언트로 플러시 된 것으로 가정 된 후에도 마찬가지입니다. 따라서 지연된 작업은 작업이 완료 될 때까지 요청 스레드를 소비하므로 요청 스레드는 그때까지 다른 요청을 처리 할 수 없습니다.
일반적으로 백그라운드 스레드를 사용하는 경우 프로세스 종료 전에 백그라운드 스레드가 완료 될 때까지 호스트 메커니즘이 대기한다는 보장이 없습니다. 사실, 기다리지 않는 표준 배포 메커니즘을 생각조차 할 수 없습니다. atexit 핸들러가 프로세스 셧다운에서 호출된다는 보장조차 없다. 참조 된 문서도 간략하게 설명하고있다.
WSGI 응용 프로그램 프로세스의 수명을 지정하지 않습니다 (더 좋은 방법이 있다면, 그 또한 괜찮을 것이다). 웹 서버와 완전히 독립적 인 방식으로 실행할 수 있습니다.이 경우 수명 만 제어 할 수 있습니다.
WSGI에는 스레드 또는 프로세스를 생성하거나 원하는 것을 수행하는 것을 금지하는 것도 없습니다.
http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode
액션의 후킹을 닫습니다() 반복자는 연기 일을위한 WSGI 사양 자체의 컨텍스트 내 유일한 방법은의 :
위대한 용어입니다. –
성능 및 스레드가 너무 많아서 서로 굶주 리지 않도록하려면 일종의 작업 대기열 + 스레드 풀 배열이 필요할 것입니다. – Marcin
@Marcin : 스레드 접근법이 실현 가능하다는 것을 보여주는 좋은 점, 그러한 인프라를 구현할 것입니다. – keppla
아직 답변을 얻지 못해 실망했습니다. – Marcin