On 09/11/2015 02:49 PM, Karl Lehenbauer wrote:
Creating interpreters only when the first request for specific virtual host comes in is a great idea! (I presume this is specifically only when running with separate virtual interpreters.) Not deleting the interpreter on process exit is a nice if small performance win for sites (like us) that have httpd children exit after handling a few thousand requests. I haven’t really followed the threading stuff closely because for our production stuff the approach of loading up the master interpreter in the httpd parent with the hundreds of packages and stuff that we use has forked children inherit an interpreter already loaded up rather than having each child load all the packages themselves is such a huge win. With the threaded approach each thread will have to load up and when hundreds are starting up simultaneously and repeatedly reading the directories along the search path and sourcing in hundreds or thousands of files each, it’s a big hit. In a hybrid model if the master could load up a bunch of threads and forked children can somehow activate those threads where they don’t have to load up and the hybrid model is a performance win over forking or something, that’d be pretty cool. Anyway, your plan of with threads having exit just exit the thread I think is really good.
This feature is already in trunk, but what we have to do now is forcing a termination, though gently, of the other threads and in turn of the whole child process in order to avoid the inevitable memory leak that otherwise would follow.
For your needs I think the threaded module could be viable only if threads could store their data in some shared memory (either shared among processes or simply shared in a process address space), keeping for themselves only the application internal state. This could combine the power of memory copy done by the fork call with the ability of threads of sharing their address space. Could package tsv help to work out a solution?
-- Massimo --------------------------------------------------------------------- To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
