Hi Andrew
Andrew Piskorski wrote:
On Mon, May 23, 2005 at 06:19:21PM +0100, Stuart Children wrote:
Certainly trial-and-error does seem to indicate that variables set
within a template do not persist across requests (ignoring nsv_*), and
What do you mean by "a template"? An ADP page? An OpenACS Templating
System Tcl/ADP pair? Something else?
Sorry, I wasn't clear - I meant within the whole scope of handling a
particular HTTP request (not including any process/thread
initialisation). So that would include perhaps AOLserver handlers,
certainly any registered procs, and finally the code that actually gets
executed (typically within a .tcl or .adp file) - though I'm primarily
concerned about the last of those.
that namespace-specific variables set during initialisation are visible
during template execution - tying in with what's suggested about cloning
a post-startup interpreter's state. The exception being global variables
which appear to be completely cleared down before each template is
executed - even if they were set during server startup.
I'm not aware of any completely definitive docs on those issues. If
you find or write some, please do let us know. :)
I'll certainly update the Wiki with any facts I can establish for
certain, and at the very least point to this discussion.
A bunch of stuff about variable persistence and risks of memory leaks
in AOLserver is buried throughout this tDOM thread:
http://www.mail-archive.com/[email protected]/msg08706.html
Ah - this indicates that [under the default configuration of
connsperthread == 0] namespaces (both their variables and procs) persist
in a thread between connections. So the interpreter is *not* re-cloned
between requests. Indeed, testing a template that increments a namespace
variable and making several requests over a keep-alive connection
demonstrates this.
What's suggested here:
http://www.mail-archive.com/[email protected]/msg08733.html
is what I was thinking was going on. For me, this would definitely be
the ideal way to do things, though with the ability to explicitly modify
the "base" interpreter (to modify: globals, namespaces, etc -
nsv_*/ns_eval style). Certainly it would make GC a great deal easier!
What are other people's view on this? Are there some who prefer the
current system of having some things (eg: globals) cleared out within a
thread but others (eg: namespaces) not?
I'd be willing to help coding on this, though my knowledge of TCL
internals (from a C POV) is currently a bit lacking. Although to be
honest I'm probably looking for a quicker solution than that seems to
entail. Perhaps Jeff Hobbs can say whether the situation WRT cloning an
interpreter within a thread has changed at all?
Two other (unrelated) questions: Firstly, it appears that when parsing
ADP, if a TCL error is encountered during a <%...%> block, AOLserver
simply logs the error, that block is replaced with an empty string in
the output (or the contents of 'errorpage' if set), and execution of the
rest of the ADP continues. My question is whether there's a way to
configure AOLserver such that execution terminates as soon as a TCL
If I remember right, Jim Davidson provided some such method a while
back. More info should be in the list archives.
Thanks for the pointer. For some reason generic AOLserver queries on
Google seem not to return the list archives very often. Anyway, I found
the thread starting here:
http://www.mail-archive.com/[email protected]/msg04685.html
- though they're after slightly more than me there, and this
'singlescript' option being implemented:
http://www.mail-archive.com/[email protected]/msg07867.html
which it looks like I could use to achieve the effect I want.
The wiki roadmap doesn't cover 4.1 (where the above was merged), so may
I ask if there're currently any release targets (either features or time
based)?
Would people would be interested in a seperate "first adp error aborts
the whole file" feature for 4.[01]? From a brief inspection of the
source, it doesn't look like it would be too terrible to implement. I'd
be willing to give this a go if the maintainers were likely to take the
patch.
Cheers
--
Stuart Children
--
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.
