On Wednesday 01 August 2007 23:53, [EMAIL PROTECTED] wrote: > > Maybe this is the intent, although it would be easy to add the > > server > > name to the key. > > ISTM that virtual servers weren't considered when this code was written ... > > All code in current versions should be fully aware of virtual servers.
The previous code in 4.0.10 was in urlspace.c and queue.c and was fully virtual server aware. The current version simply ditches this for no good reason, and by that I mean that the map storage and search are fully virtual server aware, but the threadpool creation code is a simple hash table keyed to the name of the threadpool. It also appears that on startup, two threadpools are created 'default' and 'error'. These are shared across virtual servers. Any redefinition of these affects all virtual servers. So question: we now have interps separate from threads, but what about memory, code, etc. Is this part of the interp or does it hang out with the thread? If the thread is just a clean slate, at least it is safe to reuse in another virtual server, otherwise this is a big bend over routine. But then we are left with the other option: threads pick up interps and run anywhere and everywhere on the virtual server and the interp eventually grows in size. Even if threads exit with given timeout, do interps? This negates the reason for threadpools entirely. This really needs to be discussed because the programming model could be disasterously affected and complicated by these decisions. tom jackson -- 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.
