interp naming scheme (gloomy Sunday debugging)

[Massimo Manghi <ma...@unipr.it>]

Hi

gloomy Sunday yesterday around here and I exploited the afternoon to 
take up the proposal of introducing a more resource conservative naming 
scheme for slave interpreters.

When SeparateVirtualInterp is set slave interpreters are created along a 
naming scheme expressed in the following line of code

char *slavename = (char*) apr_psprintf (p, "%s_%d_%d",
                         		sr->server_hostname,
                         		sr->port,
                         		interpCount++);

I expected sr->port to hold the port number Apache was listening to, but 
I found out it invariably held 0.The Apache source simply says 'port' in 
server_rec is there to keep the port number 'for redirects' (?) which 
probably means it's useless for the purpose we are using it. Still I 
will keep it as a basic scheme and I'm working on a new configuration 
directive named InterpNames which is accepting the value 'auto' 
(default) and 'hostname'.

The idea is to create a temporary Tcl hash table whose key is the slave 
name and values are pointers to the slave interpreters. Interpreter 
names are created either the way we do it now (default) or in a new form 
based only on the sr->server_hostname value ('hostname' value for 
InterpNames). Names are looked up in the hash and if the key exists the 
SVI server_rec is given the corresponding hash value, otherwise a new 
slave interp is created along with a new entry in the hash table.

After the interp creation loop is over the Tcl hash table can be safely 
destroyed. This is a process relatively expensive, but it's going to 
happen only once when a child process is created. I also think that a 
careful reorganization of the child process start up could exploit the 
Tcl_InitHandler method also for this, saving further time.

It seems to me the whole thing is straightforward if not trivial.

as usual comments are welcome.

  -- Massimo





---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org