Ah - I see now. Excellent question. Yes, its the 'refreshed' interps
that get us into trouble. When an interp is re-used, it checks for the
epoch change, and if so, re-runs the init script (which does not contain
the lazy procs and will not remove any procs that are already defined)
This is the same behavior that keeps ns_eval from effectively removing
procs from existing interps (with or without lazy proc). Will address
this :)
-Elizabeth
Dossy wrote:
> 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.
--
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.
