>
>In the absence of information about sharing compiled Tcl objects between
>interpreters, I can't see a way to address the memory footprint issue
>right now, but we could see if the thread startup issue helps in terms of
>time and maybe memory.
I came in on this late and missed the first posting, but won't hesitate
(sorry) to toss in my 2 cents.
If your plan works, wouldn't that to a great deal to address the memory
issues? The "enormous string" will be shared in nsv form, and each interp
will only have those functions it uses.
On the other hand, assuming that:
1. you only define functions that are used at sometime in your application
2. your interps are never destroyed
I don't know if either of those are valid assumptions. But regarding 2, a
quick examination of the code aolserver/nsd/tclinit.c, it doesn't appear to
me that interps are EVER destroyed UNLESS you specifically call
ns_markfordelete within your application or unless you call ns_eval in your
application and had ns_eval something that it bards on.
greps for markfordelete and for destroyinterp appear to reveal that nothing
in AOLserver ever deletes an interp.
So in the long run (but what is the long run), every interp will have every
function.
So while you are certainly distributing that 2-3 second per interp startup
cost over time, you aren't eliminating it.
If any of this is accurate, wouldn't another strategy just be to create a
reasonable number of threads in the beginning (using minthreads), or
creating a new parameter (mininterps) that precreates that many of interps
at startup?
I'm not saying what you guys want to do is wrong in any manner, I'm just
trying to understand how AOLserver works and what applications rl_proc will
be useful for.
Thanks,
Jerry
========================================================
Jerry Asher [EMAIL PROTECTED]
1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980
Berkeley, CA 94709 Fax: (877) 311-8688
