Yeah, I understand that httpserver code is effectively being "run" - and this code is responsible for creating the thread pool, and the worker threads handle incoming http requests, which eventually call your controller code, etc, etc, etc. This is not really the part that I was unclear about.
Let's try it this way: the httpserver code you refer to is not really executed by paster directly, is it? The httpserver code is python code (I can see the source file on my computer, it's apparently not bundled into paster.exe) that has to be parsed and executed by some instance of python., and I suspect paster does not have a built in python interpreter that it's using. Therefore, at some point, when you start "paster serve app.ini" a copy of the python interpreter is launched (not sure how?) and at some point this instance of the interpreter is really running the show. That is, the python interpreter is executing the htppserver ptyhon code, which eventually is calling your controller code, etc. In other words Paster isn't really "executing" anything as your app runs; it somehow gets the ball rolling through Python, though. It's this transition of 1) you starting paster.exe, to: 2) python ends up executing the httpserver code and your pylons code, that I want to understand better. And once Python is executing the code, what role does paster.exe continue to play? (Referring to my original post as "proof" of collaboration between python and paster: I can kill paster, yet see evidence that my pylons app is still being executed (by the instance of python). So clearly there's some point at which paster is sort of "handing the baton to python") Hope this makes sense. Any thought? Michael -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
