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.

Reply via email to