Stephen, My concern over this is that one virtual server might have slightly different code, for instance development vs. production, and would likely share the same threadpool. What exactly is part of the thread in a pool? Is there any remaining code or data from one use to another, or is all data in the Tcl interp?
The problem with ns_pools is that without explicit configuration two process wide threadpools are created: 'default' and 'error'. Now if any virtual server sets up a threadpool named 'default', the new limits apply to the process wide 'default' threadpool. This replacement or overwriting of data continues to occur for every virtual server, so the last one wins out. If it is expected that modules will configure their own pools and that these modules will be used with virtual servers, some in the same process, it is easy to predict that conficts will result. Process wide control is not compatable with module control, they can't both have access to the same settings. tom jackson On Friday 03 August 2007 13:29, Stephen Deasey wrote: > Hi, > > I think it's a fine idea that conn thread pools are a process-wide > resource. I liked the idea so much, I copied it. (Well, the limits > part, so far...) > > But I agree with you; although ns_pools/ns_limits enable some handy > new features, such as dynamic configuration, it sure would be > convenient to be able to set this from the config file. > > Here's how that works in NaviServer: > > http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tcl/config.tcl? >view=markup > > 'ns_runonce -global { ... }' is used to get around the issue you've > noticed with overwriting. AOLserver has an 'ns_ictl once' command, but > IIRC it's once per-virtual server only, I'm afraid. > > > Couple of other misconceptions/questions were raised: > > Tcl interps belong to the thread which created them. If there's more > than one virtual server configured, there's one interp for each > server, per-thread. > > > Tcl objects are reference counted. The Tcl documentation hints that > when your C implementation of a command begins, the interp result is > in a pristine state. it's value is "". You might also expect it to be > unshared. But sometimes it's not! > > So you can't do the obvious: > > Tcl_SetIntValue(Tcl_GetInterpResult(interp), 1); > > and instead have to: > > Tcl_SetObjResult(interp, Tcl_NewIntValue(1)); > > It's tempting to do the first because it looks faster. Anywho, it's > not a threading issue. > > > Hope that helps. > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the > email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
