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.
-- 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: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
