As far as a fork call is concerned seems to be reasonable. I can try to merge
this goal with my experiments on creating a server interp that could be used
to init ipc mechanisms. My first attempt created a standalone interp without
the usual initialization interpreters go through, but perhaps I can merge the
two goals.

I've just created a 'master-interp' development branch to experiment with it.
I will commit there any improvement on this goal.

 -- Massimo

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 
> 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.
> 
> Per-page processing would continue unmodified.
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to