On Thu, May 15, 2008 at 6:52 PM, Vasiljevic Zoran <[EMAIL PROTECTED]> wrote: > > 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?
You mentioned that you didn't want to rewrite a complicated state machine that uses a lot of uplevels, in an event style. I thought maybe you could keep the variables separate using these namespace lookup procs. Then you could use a single interp to manage multiple state machines, instead of using the stacks of 1000 threads. You could give each client an id on first connect and put them in buckets, with buckets >=1 and <= 1000. You need a pool of threads, one for each bucket. When a message arrives from a client, you sent it to the same thread/bucket each time. The interps of those threads are persistent. Within the bucket interps you use the namespace lookup trick to subdivide the variable space between the clients which are assigned to that interp. The interp runs a client message to completion, then picks up the next. Your concurrency level is however many buckets you decide to subdivide the 1000 connections into. ------------------------------------------------------------------------- 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
