On Fri, 14 May 1999, David P. White wrote:
> I intend to deploy JACL in a server-side process whereby clients make
> server requests that TCL code be run on their behalf. Each client's
> request will run in a JACL interpreter.
>
> I was thinking of reducing overhead by creating a pool of shared
> interpreters rather than instantiating one for each new client request.
> However, each request may cause the creation global variables, procs,
> etc which should not be in place when the next client request comes
> along.
>
> So if I am to use a pool, I need to be able to "clean-up" the
> interpreter when it is returned to the pool. I could do this by
> interating over the lists returned by [info globals], [info procs],
> [info loaded], etc and perform tcl code to unset variable, clear
> procedures, and forget packages, etc.
>
> However, I wonder if:
You should be able to. As long as you do not "clean up" the global
variables that Tcl uses then you should be just fine. Variables and
Procs are easy to undo but packages are another matter. As far as
I can tell, Tcl does not support the concept of "unloading" a package.
Of course if you just want to reset the interp state to its original
state, then you could just remove all the user defined procs and
not worry about which packages created them. This also seems like
the whole reason for the "interp" command in regular Tcl. It provides
a way to create and delete child interps inside a known interp where
you set the initial interp state (what vars and procs are defined).
The catch is that Jacl does have a working implementation of the inter
command. The upside is that it should not be too hard to add to Jacl.
> (1) I can really do a complete "clean-up" this way,
I have no idea which way would be faster. Most of the "slowness"
of creating the first interp is related to the loading of .class
files for the commands that are used. Once the first one is
created it seems like making a new Java interp object would not
be all that slow. Has anyone else on the list tried to do
this before? If so could you comment on your results.
later
mo
> (2) If this approach is faster than simply instantiating new
> interpreters as needed and killing them off when done,
>
> (3) If there is some built-in method that can be called to do this.
>
> Any thoughts/hints are appreciated.
>
> Thanks,
>
> David P. White
> HMS Software
>
> ----------------------------------------------------------------
> The TclJava mailing list is sponsored by WebNet Technologies.
> To subscribe: send mail to [EMAIL PROTECTED]
> with the word SUBSCRIBE as the subject.
> To unsubscribe: send mail to [EMAIL PROTECTED]
> with the word UNSUBSCRIBE as the subject.
> To send to the list, send email to '[EMAIL PROTECTED]'.
> A list archive is at: http://www.findmail.com/listsaver/tcldallas/
----------------------------------------------------------------
The TclJava mailing list is sponsored by WebNet Technologies.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
A list archive is at: http://www.findmail.com/listsaver/tcldallas/
