On 2003.08.21, Elizabeth Thomas <[EMAIL PROTECTED]> wrote:
> Only new or 'refreshed' interps will get the new values (since they will
> have a pristine interp that is associated with the new nsv array).
> Existing interps will use purely the old values (since they have an old
> interp that is associated with the old nsv array). In the interp
> performing the ns_eval, it will evaluate the file, so the new
> definitions take effect there, and no 'unknown' processing kicks in for
> them. Does these cover the scenario you are envisioning?
Here's a sample scenario:
In page code, suppose I have the snippet "<% foo %>". In my Tcl lib
dir, I have foo.tcl and inside it, is:
proc foo {} {
ns_adp_puts foo
}
I hit the page, and with lazyprocdef turned on, assuming a new thread
and interp had to be created to serve this request, attempting to invoke
the "foo" proc, which doesn't exist in the interp as a proc yet, causes
the unknown proc to get invoked. That in turn creates the proc as it's
defined in the nsv store. Then, the actual foo proc is invoked.
Now, what happens if I issue "ns_eval proc foo { ns_adp_puts bar }" from
the nscp port?
New interps will see the new foo def, but the interp that served the
previous request now has a real proc foo defined, and thus won't hit the
unknown proc or see the new def in the nsv store.
IMHO, if this is what's happening, it's a problem. It breaks the
contract that ns_eval is supposed to fulfill.
Ideally, when ns_eval happens, it should instruct all the interps get a
list of all the procs that are defined in the nsv store, and rename
$proc {} them away -- so that the next attempt to invoke a proc goes
through the unknown proc and refreshes the proc def from the nsv store.
Is the lazyprocdef stuff checked into CVS now?
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
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.
