A preliminary implementation of this scheme was successful with minimal efforts. I haven't tested yet what happens when SVI are turned on and I'm still using the rivet_server_init_script variable I had created.
I put in the conf the line RivetServerConf ServerInitScript "package require Tclx" which is run in Rivet_InitHandler, and then I requested the execution of a .rvt file, where the existence in interp of package Tclx was tested using 'package present Tclx": the package was in the interpreter (naturally the server hadn't been run with the '-X' switch....;-)) On Thu, 20 Jan 2011 18:28:43 -0600, Karl Lehenbauer wrote > I've looked at this a little further. I think we would create the > parent interpreter in the httpd parent process in Rivet_InitHandler() > , which is invoked during http initialization because it was passed > to ap_hook_post_config() by rivet_register_hooks(). > > At this point, the interpreter in the parent httpd process, we'd > initialize it with the normal Tcl_Init-type stuff and then execute > any global init scripts. Again, this all happens within > Rivet_InitHandler when there is only the one httpd process running. > > As the parent process forks off all the httpd children, each child > has Rivet_ChildInit() called, as before, because Rivet_ChildInit was > passed to ap_hook_child_init() by rivet_register_hooks(). > > Rivet_ChildInit() would be modified to use the interpreter created > by Rivet_InitHandler(), unless separate virtual interpreters was the interpreter pointer is kept in the rivet_server_conf structure which is copied by 'fork' into the address space of the newly created child process, so actually Rivet_ChildInit did not need to be modified. > defined, and then instead of doing all that interpreter creation > stuff in Rivet_InitTclStuff(), like it does now, it would do the > Apache stuff it needs to do and also execute the child init scripts > on the interpreter it inherited from the parent when the parent > forked it off. > -- Massimo -- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
