> On Sep 11, 2015, at 4:18 AM, Massimo Manghi <[email protected]> wrote: > > As no answer or suggestion followed this proposal I will implement it and > commit it in trunk. Then, in order to mitigate the possible interpreter > termination/initialization storm that might ensue an inappropriate usage of > the 'exit' command (we don't delete interpreters anymore but child exit > scripts must run anyway), I will implement a two states machine in the > threads of the rivet_worker_mpm bridge. Interpreters will be created and > initialized only when the first request for a specific virtual host comes in.
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. > > -- Massimo > > On 09/07/2015 12:15 AM, Massimo Manghi wrote: >> Hi everyone >> >> I'm CC'ing also Alexandre Ferrieux as his opinion on the subject is >> authoritative. >> >> In the wake of the ticket opened by Anton on core.tcl.tk we are facing >> the need to change the way we handle child process (prefork MPM) and >> thread (worker MPM) terminations. We are now recommended to avoid to >> delete explicitly an interpreter when a child process goes away: it's OK >> with the prefork bridge (and in the 2.2 module) but there are >> implications for the threaded model. >> >> With the worker MPM we implement our own exit command which shadows the >> Tcl core command. This is needed by the sheer existence of the command >> which I gather eventually calls Tcl_Exit which in turn tears the whole >> child process down. In a threaded bridge like rivet_worker_mpm you would >> have all the threads abruptly interrupted just because somewhere in a >> different thread, likely running a different application, a programmer >> placed an exit command. Hence our exit code simply tells the thread from >> where it was called to exit, to notify the supervisor and clean >> everything to avoid leaks (Tcl interpreter firstly) >> >> If we want homogeneity between the two MPM models we should consider to >> tell all the threads to gently exit and then let the child process exit >> as well, I don't see any other sensible approach, even though the >> overhead of having many threads exit and then restarted just as a side >> effect of invoking exit is kind of disturbing to me >> >> >> -- Massimo >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
