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?
-E
P.S. I'm sure more questions will be answered (and probably even more
asked) when I publish the proposed changes - but they need some final
touches :)
Dossy wrote:
> On 2003.08.21, Elizabeth Thomas <[EMAIL PROTECTED]> wrote:
> >
> > To handle ns_eval (which is indeed evil), we must create a copy of the
> > nsv arrays for each ictl epoch. To do proper garbage collection we need
> > to keep track of reference pointers so we can dump the older ones once
> > they are no longer referenced.
>
> On ns_eval, do we "rename procName {}" away all procs defined in the nsv
> store, so that the next call to the proc pulls out the fresh definition
> from the nsv store?
>
> -- 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.
