>Here's another variant which could be useful. AOLserver 4.0 allows you to
>load the nssock driver outside a specific virtual server and then map to
>virtual servers via the Host header. As with old 2.x virtual servers, you
>can then have separate virtual server configs, for example, separate access
>log files. There's an example of such configuration in the sample-config.tcl
>-- I've pasted it below.
With this approach, all virtual servers share the same Tcl interpreter
pool, right? Or does each virtual server get its own interpreters, not
shared with the other virtual servers?
As with 2.x, each virtual server gets it own Tcl state. This is handled in the code by storing per-server Tcl state (e.g., library directory) in the tcl struct within the NsServer struct which is pointed to by the NsInterp struct, often the clientData passed to the various Tcl commands. Got that :) A code snippet for the ns_info command shows how this works for "ns_info library".
The merits of virtual servers have been debated for some time back here at AOL. The feature/complexity got into the code as part of our web hosting initiatives back in 1995, we don't use it now. It's back in 4.0 really for completeness. I suspect folks who are interesting in big hosting setups may find value in the approach.
-Jim
int
NsTclInfoObjCmd(ClientData arg, Tcl_Interp *interp, int objc, Tcl_Obj **objv)
{
NsInterp *itPtr = arg;
char *elog;
Tcl_DString ds;
....
case ITclLibIdx:
case IPageRootIdx:
case IServerIdx:
if (itPtr->servPtr == NULL) {
Tcl_SetResult(interp, "no server", TCL_STATIC);
return TCL_ERROR;
}
if (opt == IServerIdx) {
Tcl_SetResult(interp, itPtr->servPtr->server, TCL_STATIC);
} else if (opt == ITclLibIdx) {
Tcl_SetResult(interp, itPtr->servPtr->tcl.library, TCL_STATIC);
} else {
Tcl_SetResult(interp, itPtr->servPtr->fastpath.pageroot, TCL_STATIC);
}
}
