On 07/18/2013 08:39 AM, Harald Oehlmann wrote: > Please, would you share your patch to Tcl? Have you considered about a TIP? > > Well, I have done everything I thought is appropriate: > - message on clt - question if it is a bug fix or a tip required > - branch on core.tcl.tk/core > - rfe there > - documentation everywhere around 5 times... >
The tests I proposed were aiming at establishing under which conditions a whole plain Tcl system, built out the original distribution, can be safely recreated in a child process through a fork call. > To fix it without this tcl patch, I suppose we can only create the > interpreter in child initialisation and have to withdraw the forking of > interpreters... > I understand that we should give the programmer a chance to have the Tcl interpreter they're expecting to have. A basic solution is disabling the master interpreter creation in the parent process depending on the value of a configuration parameter (a better alternative would be to shut down Tcl and its subsystems before it forks). The user must go either the fast compact way of creating an interpreter or the slower way granting a full-fledged Tcl interpreter with all its subsystems working. We may also adopt the mixed (maybe better) approach I quoted before: Tcl is shutdown by configuration demand before Apache forks leaving a chance to run a server initialization script (useful in many cases because guaranteed to not clash with other processes). Personally I haven't been able to shutdown Tcl by calling Tcl_Finalize in Rivet_InitHandler (I got a segfault). I admit I haven't tried very hard and I could go back on it. Actually I don't like the idea of using the configuration to chase a solution to problems arising from the pitfalls of the interaction between Unix and Tcl, but do we have alternatives? > I have reasoned the requirement by the fact, that the following feature > saved 40 minuites of boot time for FlightAware (what I think I have read > here): > > - Start master interpreter > - source packages > - fork a client interpreter > - open data base connections etc. > > If not so, we should revert this, and just do all of that after the fork. > I'd like to hear from the FA guys on this. FWIK they had a tremendous improvement in the startup of their application. This feature has some limitation though, even when you are not demanding the notifier to be working. Slave interpreters generation don't propagate the packages initialization to slave interpreters, therefore if SeparateVirtualInterps is on you cannot share among virtual hosts a common ground of preloaded packages. (Would this be worth a TIP requiring to extend the slave interpreter command to support initialization) cheers -- -- Massimo Manghi Dipartimento di Neuroscienze Unità di Biofisica e Fisica Sanitaria via Volturno 39 43125 Parma --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
