On May 21, 5:06 am, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > On May 21, 7:00 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> > wrote:
....... > > There is much to cover in this - and I suppose reason to be happy that > > python traditionally hasn't run multi-core. > > See, for example, the discussions > > at:http://stackoverflow.com/questions/203912/does-python-support-multipr... > > > andhttp://docs.python.org/library/multiprocessing.html > > > Lots to read! ;-) > > Also read: > > http://blog.dscpl.com.au/2007/07/web-hosting-landscape-and-modwsgi.html > http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modws... > > BTW, your prior descriptions about how web2py works under mod_wsgi > aren't overly accurate. You said: > > """ > In a hosting environment, you have apache/wsgi (for example) running > a > wsgi-thred that is web2py - that (main and the stuff in gluon) is > your > long-running process (er, thread). To restart web2py, with wsgi, > you > would do what is normal (touch a file) to cause apache to re-start > that wsgi thread. > > Within web2py, you have a number of threads: db connection pools, > and > application threads; again, these respond to requests, and are > spawned off by web2py (not you) > """ > > When run under Apache/mod_wsgi there is not a thread that is dedicated > to web2py and web2py doesn't have its own threads to respond to > requests. > > In each Apache or mod_wsgi daemon process, depending on whether you > are using embedded mode or daemon mode, there is a pool of threads. > These are C threads, not Python threads and the thread pool is managed > by Apache or mod_wsgi as appropriate. > > How a connection is accepted depends on Apache MPM or mod_wsgi mode > being used, but ultimately one of the threads in the thread pool > processes the request, all still in C code. For embedded mode the > request may not even be for the WSGI application but be for a static > file or other dynamic application such as PHP. If daemon mode, or if > target of request was the WSGI application, only then does Python GIL > get acquired and the thread tries to call into the WSGI application as > an external thread calling into the embedded Python interpreter. > > At this point the WSGI application may not have even been loaded, so > the first request to find that has to load the WSGI script file which > may in turn load web2py. In this case web2py doesn't do anything > special. That is, it doesn't go creating its own thread pool and it > actually must return immediately once it is loaded and initialised. > Once it returns, the thread calls into the WSGI application entry > point and web2py handles the request. Any response is thence passed > back through Apache with the GIL being released at each point where > this occurs. When complete request is done, the GIL is completely > released and thread becomes inactive again pending a further request. > > If other requests occur at the same time, they could also call into > web2py. The only choke point is the initial loading of the WSGI script > as obviously only want to allow one thread to do that. > > So, web2py doesn't have its own request threads and all calls come in > from a external threads managed by Apache or mod_wsgi. > > Graham Thank you, Graham - Your clarification is clear, and much appreciated! Regards, - Yarko > > > - Yarko > > > > On May 20, 2:12 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> > > > wrote: > > > > > On May 19, 6:18 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> > > > > wrote: > > > > > > On May 19, 5:41 pm, amoygard <amoyg...@gmail.com> wrote: > > > > > .... > > > > > > So - in general, you do not start subprocesses - with the exception of > > > > > cron. Seehttp://www.web2py.com/book/default/section/4/17 > > > > > I might better have said you do not _want_ to be starting subprocesses > > > > - besides the cost (compute time, memory, etc.), if you generally did > > > > this. This (the inneficiency of spawning subrocesses) is why > > > > stackless was created - and (among other things) used in a a very > > > > busy online game. A lot of thought went into avoiding the costs of > > > > spawning subprocesses. > > > > > If you haven't heard of it, stackless is an implementation of python > > > > that does not use the traditional "C" stack for local variables, > > > > etc. Among other things, it has added "tasklets" to the language, so > > > > you can create and schedule tasks - without the overhead of doing so > > > > in your operating system. There is a lot of discussion of benefit, > > > > efficiency. Although there might be some discussion questioning the > > > > approach, other alternative approaches, one thing is clear: the > > > > motivation to stay away from creating threads / subprocesses, and the > > > > costs involved. it might be interesting to read up on it. > > > > > - Yarko > > > > > > - Yarko
