In daemon mode requests are never handled in the true main Python thread. Only the pre-loading occurs in the main Python thread.
What you were likely seeing was the result in what could be argued is a bug in the Python threading module in that it calculates incorrectly what is the main Python thread. The problem with Python threading module is that it assumes that whatever thread first imports the threading module is the main thread, yet the Python interpreter on initialisation doesn't actually import the threading module, so that can't actually be guaranteed in an embedded system, where the first call into the interpreter to execute Python code and which imports the threading module may be an external thread and not the same main thread which created the Python interpreter in the first place. In your original case what was occurring was that the first, and only request thread, got designated due to this incorrect assumption in the threading module as the main Python thread when it actually wasn't. When you enabled preloading, where the script is preloaded using the true main Python thread, it correctly gets designated as the main thread by the threading module. The request thread then is properly seen as not being the main Python thread. The latest develop branch of mod_wsgi actually has a change which overrides this wrong behaviour of the Python threading module by forcibly importing the threading module in the main thread just after the Python interpreter is initialised. Thus it ensures that request threads never wrongly get reported as the Python main thread when pre-loading isn't being used. In other words, the behaviour you see when you enable pre-loading is actually the correct behaviour and means the wrong behaviour of the threading module doesn't happen. So the question now is what are you doing that has to be done in the main thread and can't be in a secondary thread? If can understand that can explain what you need to do to change your code to handle that requests always run in secondary threads. Also be aware that when you specific process-group and application-group to WSGIScriptAlias, you don't actually need to set WSGIProcessGroup and WSGIApplicationGroup as the options on WSGIScriptAlias take precedence and override them anyway. Graham > On 11 May 2021, at 8:27 pm, Swapnil Ojha <[email protected]> wrote: > > I am using apache(2.4.6) with mod_wsgi(4.6.5) in daemon mode. I am currently > working on a project which needs to preload the WSGI application. > > This is the configuration i was using before: > > <VirtualHost *:8080> > DocumentRoot /path/to/repro/wwwroot > WSGIDaemonProcess repro processes=1 threads=1 display-name=repro > maximum-requests=0 > WSGIProcessGroup repro > WSGIScriptAlias /repro /path/to/repro.py process-group=repro > WSGIApplicationGroup %{GLOBAL} > </VirtualHost> > This is the repro.py file: > > import os > import web > import sys > import threading > urls = ( '/', 'index' ) > class index: > def GET(self): > print(threading.main_thread()) > print(threading.current_thread()) > print(threading.enumerate()) > return "Hello, world!" > > application = web.application(urls, globals()).wsgifunc() > According to the following two resources: > > enable to initialize other python module before first request (Django + > mod_wsgi + apache) > <https://stackoverflow.com/questions/43941192/enable-to-initialize-other-python-module-before-first-request-django-mod-wsgi> > https://modwsgi.readthedocs.io/en/master/configuration-directives/WSGIScriptAlias.html > > <https://modwsgi.readthedocs.io/en/master/configuration-directives/WSGIScriptAlias.html> > I changed the configuration to this: > > <VirtualHost *:8080> > DocumentRoot /path/to/repro/wwwroot > WSGIDaemonProcess repro processes=1 threads=1 display-name=repro > maximum-requests=0 > WSGIScriptAlias /repro /path/to/repro.py process-group=repro > application-group=%{GLOBAL} > WSGIProcessGroup repro > WSGIApplicationGroup %{GLOBAL} > </VirtualHost> > i.e specified both application-group and process-group directive. This solved > the pre-loading problem for us. > > But, the difference here is that in the first case all the requests were > being handled by the main thread but after the configuration change, the > requests are now being handled in the non-main thread. We have a bunch of > code that requires things to be run on the main thread and were running > previously but after the change, it is causing them to fail. > > I tried reordering WSGIApplicationGroup and WSGIProcess group directive but > that didn't work. The only thing that worked was the removal of > application-group from WSGIScriptAlias but that then would not preload the > wsgi app. Could you please suggest to me what other things I could try? > > Thank you for your time! > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/modwsgi/eb747f16-10b2-48c3-9ce3-2da6a3ef383fn%40googlegroups.com > > <https://groups.google.com/d/msgid/modwsgi/eb747f16-10b2-48c3-9ce3-2da6a3ef383fn%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/modwsgi/73F89892-34E0-425B-972D-3965C07A86B7%40gmail.com.
