On 09.05.2008, at 20:44, Vasiljevic Zoran wrote: > What MIGHT work is kind of this: create some numbers of > fully loaded interps, each sitting in its own thread. > A compute-farm, so to say. Then every other thread just > creates a slave interp in one of those and runs all its > scripts in his private slave in one of those parked threads > in the compute-farm, using some kind of message passing. > The slaves have all the commands aliased into the main > one. Not sure what would happen with uplevels and upvars > here (need to think) but this is roughly what I'm > contemplating about now.
Upvars/Uplevels will not work. No way. > So when a thread exits, its > thin-slave is just deleted completely. And created it is > also fast. Just alias all commands from the master. Not > sure about the global variables... this is still open. No access to variables... So: no generic solution as I was looking after. FWIW... For those interested: on a Mac PB, using Tcl8.4 and current threading extension, I can load 1000 threads with virgin interp and this costs me about 700MB virtual memory. Dont know about the thread stacks, if I reduce the default, perhaps it will be less (platform specific anyway). But this is acceptable footprint. After all there are 1000 units of execution! If I now just blindly override the [::unknown] command in each of them and go look in a round-robin fashion for a idle "mother" interp (one loaded with all that fancy app state) and execute the "real" command there, instead in my tiny little per-user thread, then this could work fine. Admitently, this is _similar_ to [ns_job] or [therad::send] but it is more "implicit" in the sense that you need not program with [ns_job] of [thread] Tcl API. One can just simply program in plain Tcl, provided the application allows following limitations: no upvars no uplevels no direct variable access no references (channel handles, or other types of handles) Just plain command dispatching. The command may only return things "per-value" (lists, scalars) i.e. something that can be cheaply converted to string. References/hndles are not allowed. Those limitation are actually not bad: they force the programmer to encapsulate the app logic within manageable self-contained blocks. So, at the end... the only "trick" is to create a virgin interp, overload the [::unknown] command and re-route the execution to a farm of pre-parked and loaded interps using in-memory message-passing. Those are all created "equal" and can be created and destroyed on as-needed basis i.e. dynamically (actually, the Naviserver already provides this in form of ns_job and threading extension in form of thread-pools). I will give this a second thought... If this holds water I will see if I can do this in a reasonably generic fashion for general (purpose) usage. Cheers Zoran ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
