On 11.05.2008, at 15:42, Stephen Deasey wrote: > > Undocumented: > > generic/tclResolve.c: Tcl_AddInterpResolvers() > > > > You could probably even fake-up a solution using a single interp with > your own name resolvers. Before you start executing the code for a > single client, set a 'context' global which your resolver routines > will use to keep state variables separate for each client.
Hmhmhm... I do not really follow.... I cannot do that with a single interp. As it is bound to a thread. So - single interp - single thread. How do I scale? I normally have, say, couple of hundred of connections to the server, all with a separate state. The simple and most straight forward is to keep that state (a connection socket to the client, client's private data) in a per-client sandbox. At the moment a Tcl interp and separate thread give me the needed "sandbox". Yet, currently that would blow the servers memory given my app metrics. To make the sandbox small, I just create an empty interp and route (message-passing) API calls to _something_ else. This keeps the sandbox reasonably small. I was hoping to find a generic solution to this, yet I do not know how :-( My only chance is to rewrite (or write new) app logic that encapsulates the required functionality in a high-level API and then route API calls to a battery of equally-created-threads, each fully loaded with the complete command set and state. The [ns_job] is quite a good example to what I need. But it is clumsy to use. Ideally, one would just call API calls directly in Tcl and that would automagically be ran in some distant/other interp. Well, that means, of course that API needs to be completely wrapped in the sense that I can only communicate scalar values with it (no refrerences, file handles, other handles etc pp) as the whole API state is uknown in the sandbox AND I have no per-interp affinity in my "computing-battery-of-threads" as this would limit my scalability. Now, I hope I managed to convey the picture. How do you see the above Tcl API could help me? What I understand is that this is ment to be helpful for extension writers to impmenent new language extensions (oo systems in particular) with custom var and command resolvers but all this is private to the calling thread. Or isn't it? Cheers Zoran ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
