Re: [naviserver-devel] moonshadow
On Sat, May 10, 2008 at 05:50:42PM +0200, Vasiljevic Zoran wrote: > Since some years I've been trying various approaches how to tackle > this problem but I really found no realy good and universal way. > I believe there isn't one, after all those years. I will try just this No, I believe that there certainly must be a good solution to your sort of problem. Whether there's any nice incremental solution in your case is much less clear! E.g., "Rewrite your entire app in Erlang." is probably not a useful solution for you, and would have its own very substantial risks and uncertainties. I certainly encourage you to continue picking the brains of the folks who have serious deep knowledge of the Tcl interpretor's design and implementation. (E.g., I certainly don't understand WHY the Tcl compiled bytecode is somehow magically linked to and usable only by the interp that created it. Why can't you have a single memory region with bytecode used by all 1000 independent interps?) > one more idea with unknown-overloading and dispatching unknown command > to a battery of preloaded interps living in different threads. Although Yes, avoiding having an entire heavyweight Tcl thread + interp for each one of your thousands of client connections is probably the way to go in your case. You're going for some sort of threadpool design instead. But, it IS rather ugly that memory usage from 1000 redundant copies of identical code FORCES you down that road. > Hopefully I will soon find piece of mind with this issue and stop > going on other people's nervers and saturate email lists :-) Not at all, I think you are tackling an inherently interesting problem, which if solved well, would definitely be useful to others too. I think the main reason YOU are stuck tackling this, is that there simply aren't all that many people who REALLY want or need your 'thousands of lightweight processes' use case. And of that set of people, you might be the only one who happens to be doing it with Tcl (and Naviserver), rather than one of the other dozens (or hundreds?) of plausible programming languages and toolkits. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ - 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
Re: [naviserver-devel] sample config
If you want to work on that take a look on nsconf module, i tried to collect all config options with small description there. Could be a starting point for the man page. Vasiljevic Zoran wrote: > Hi ! > > In the process of a spring-cleanup I wanted to attack > the gobal sample-config.tcl file that we deliver > with the server. The purpose of that file is obviously > dual: > > o. get a config file people can start with > o. declare and document each and every config option > > As it seems, we fail to meet any of those goals _really_. > One can use this file to start the server, right, but > thats about it. Any attempt to understand it, is not > going to bear fruits... > > I will reorganize this file as follows: > >o. write man page about the overal layout of the file >o. write man page explaining server internal parameters >o. expand man pages for each module and put explanations > of module paramaters there >o. rewrite this file to include sample for configuring > two virtual servers > > Since we now have man pages in place, logical place to > put all possible documentation and description of options > is there. In the config file we can put only really necessary > stuff that is needed to startup some example configurations > and put cross references to the documentation. > > Vlad already started this right by providing a minimal > no-fuss config file for somebody that needs to pull up > the server fast with minimal config. What we need is > something similar to that for virtual servers in perhaps > 2 or 3 sample configurations. But we should NOT put docs > in that files. We should write docs in man and put only > refs to that in the config files. > > Any other ideas? Suggestions? > > 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 > -- Vlad Seryakov [EMAIL PROTECTED] http://www.crystalballinc.com/vlad/ - 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
Re: [naviserver-devel] ns_perm module bug fix
Added Daniel Stasinski wrote: > On Sat, May 10, 2008 at 12:33 PM, Vlad Seryakov <[EMAIL PROTECTED]> wrote: >> Do you need write access to naviserver CVS? > > That would be great. Thank you. > > Daniel > -- Vlad Seryakov [EMAIL PROTECTED] http://www.crystalballinc.com/vlad/ - 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
Re: [naviserver-devel] ns_perm module bug fix
On Sat, May 10, 2008 at 12:33 PM, Vlad Seryakov <[EMAIL PROTECTED]> wrote: > Do you need write access to naviserver CVS? That would be great. Thank you. Daniel -- | --- | Daniel P. Stasinski | http://www.saidsimple.com | [EMAIL PROTECTED] | http://www.disabilities-r-us.com | XMMP: [EMAIL PROTECTED] | http://www.avenues.org | Google Talk: mooo | http://www.scriptkitties.com - 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
Re: [naviserver-devel] ns_perm module bug fix
Do you need write access to naviserver CVS? Daniel Stasinski wrote: > On Sat, May 10, 2008 at 8:32 AM, Vlad Seryakov <[EMAIL PROTECTED]> wrote: >> patched, submitted. Thanks > > I just committed it to aolserver cvs also. > > Daniel > -- Vlad Seryakov [EMAIL PROTECTED] http://www.crystalballinc.com/vlad/ - 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
Re: [naviserver-devel] ns_perm module bug fix
On Sat, May 10, 2008 at 8:32 AM, Vlad Seryakov <[EMAIL PROTECTED]> wrote: > patched, submitted. Thanks I just committed it to aolserver cvs also. Daniel -- | --- | Daniel P. Stasinski | http://www.saidsimple.com | [EMAIL PROTECTED] | http://www.disabilities-r-us.com | XMMP: [EMAIL PROTECTED] | http://www.avenues.org | Google Talk: mooo | http://www.scriptkitties.com - 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
[naviserver-devel] sample config
Hi ! In the process of a spring-cleanup I wanted to attack the gobal sample-config.tcl file that we deliver with the server. The purpose of that file is obviously dual: o. get a config file people can start with o. declare and document each and every config option As it seems, we fail to meet any of those goals _really_. One can use this file to start the server, right, but thats about it. Any attempt to understand it, is not going to bear fruits... I will reorganize this file as follows: o. write man page about the overal layout of the file o. write man page explaining server internal parameters o. expand man pages for each module and put explanations of module paramaters there o. rewrite this file to include sample for configuring two virtual servers Since we now have man pages in place, logical place to put all possible documentation and description of options is there. In the config file we can put only really necessary stuff that is needed to startup some example configurations and put cross references to the documentation. Vlad already started this right by providing a minimal no-fuss config file for somebody that needs to pull up the server fast with minimal config. What we need is something similar to that for virtual servers in perhaps 2 or 3 sample configurations. But we should NOT put docs in that files. We should write docs in man and put only refs to that in the config files. Any other ideas? Suggestions? 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
Re: [naviserver-devel] moonshadow
On 10.05.2008, at 18:15, Vlad Seryakov wrote: > What will happen if 100 threads will send commands at the same time > and > those commands will be more complicated, not just return? > > Main thread will serialize them, i guess. > Does not it seems like global lock in Lua? > Will it scale the way you want it to scale? I believe it will. It is all compromise and it sacrifies speed for memory, obviously. But you could decide how much memory you burn and how fast the system is by tuning the number of workers. At the moment we cannot tune much. All our interps are created equal and all are fully loaded. I would create a number of those heavy interps upfront and make "connection" threads as lightweight as possible (just basic Tcl commands plus ns_ commands). I would instrument the unknown command in them so all that gets executed in the connection thread, gets really excuted in one of those pre-started things, unless it is the ns_ or regular Tcl command. This requires certain conventions in the app but it would I believe scale very well. - 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
Re: [naviserver-devel] moonshadow
You may also check out SpiderMonkey javascript. It is thread safe and
runtime is not very big.
Vasiljevic Zoran wrote:
> On 10.05.2008, at 06:13, Andrew Piskorski wrote:
>
>> On Fri, May 09, 2008 at 06:06:05PM +0200, Vasiljevic Zoran wrote:
>>
I saw somewhere that Lua can have global and per-thread state
and that you can provide your own locking primitives they use
to lock their own code, but I haven't dig deeper there...
>>> Damn again. This is a global lock that serializes everything.
>>> A no go :-(
>>> Same applies to others (Ruby, Phyton, Perl).
>> Zoran, are you SURE? Because from what I've read about Lua, it does
>> NOT have any sort of single global lock limiting true parallelism to
>> one cpu/core at a time the way Python and Ruby do. Lua's default
>> behavior is coroutines cooperatively multitasking on just a single
>> cpu, but AFAIK the Lua implementation is not inherently limited to
>> that.
>
> Coroutines are something similar, (purists outthere, note: _similar_)
> to Tcl event loop in terms that they work on a single processor.
> This is not real MP multithreading that we need in order to scale.
> From the programing perspective, they are indeed very interesting
> because they don't force me into the "event-loop" shoe. I have
> nothing against event-loop. It is just that it is really targeted to
> a GUI type of apps.
> I was greping to "lua_lock" calls arround the code and found mostly:
>
> something () {
>lua_lock(L);
>//...
>lua_unlock(L);
> }
>
> OK, this must _not_ mean they are absolutely serialized, but it
> really appears to me like that on the first glance.
> What I plan to do is go to Lua developers and ask couple of
> questions...
>
>>
>> Your application clearly wants to use many thousands of stateful
>> lightweight processes. AFAIK Lua and especially Erlang both support
>> that out of the box. Do you ALSO need to run 2 or 8 or more of those
>> threads in parallel (at the exact same time) on a single multi-cpu
>> server? Recent versions of Erlang definitely support that. I'm not
>> sure whether or not Lua supports that out of the box, but it may be
>> feasible to make it work.
>
> Yep, Erlang is something that looks very good as well. I just stumbled
> across that yesterday. Clever, clever... still I have to see how
> they works internally and what are the gotchas of their message-passing.
>
> 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
>
--
Vlad Seryakov
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
-
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
Re: [naviserver-devel] moonshadow
What will happen if 100 threads will send commands at the same time and
those commands will be more complicated, not just return?
Main thread will serialize them, i guess.
Does not it seems like global lock in Lua?
Will it scale the way you want it to scale?
Vasiljevic Zoran wrote:
> On 10.05.2008, at 17:50, Vasiljevic Zoran wrote:
>
>> I think
>> it is the most one can do with Tcl.
>
>
> Hm ... not that bad consider the
> trivialiy of the example.
>
> package req Thread
> set tp [tpool::create -initcmd {
> proc sayhello args {
> return hello-[thread::id]
> }
> }]
>
> proc unknown args {
> global tp
> set id [tpool::post $tp $args]
> tpool::wait $tp $id
> tpool::get $tp $id
> }
>
> % time {sayhello} 100
> 48 microseconds per iteration
> % sayhello
> hello-tid0xb0103000
> % thread::id
> tid0xa0111fa0
>
> As you see, unknown triggers the sayhello that is declared
> on pool threads, but not in my thread. And the execution
> time is not really bad. And this is just generic stuff.
> Done in C really tight, I can go make that 1/5 most probably.
>
>
>
>
> -
> 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
>
--
Vlad Seryakov
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
-
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
Re: [naviserver-devel] moonshadow
On 10.05.2008, at 17:50, Vasiljevic Zoran wrote:
> I think
> it is the most one can do with Tcl.
Hm ... not that bad consider the
trivialiy of the example.
package req Thread
set tp [tpool::create -initcmd {
proc sayhello args {
return hello-[thread::id]
}
}]
proc unknown args {
global tp
set id [tpool::post $tp $args]
tpool::wait $tp $id
tpool::get $tp $id
}
% time {sayhello} 100
48 microseconds per iteration
% sayhello
hello-tid0xb0103000
% thread::id
tid0xa0111fa0
As you see, unknown triggers the sayhello that is declared
on pool threads, but not in my thread. And the execution
time is not really bad. And this is just generic stuff.
Done in C really tight, I can go make that 1/5 most probably.
-
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
Re: [naviserver-devel] moonshadow
On 10.05.2008, at 06:23, Andrew Piskorski wrote: > So you probably have 10 MB or so of proc definitions, which are 95+% > or even 100% identical in every thread, but Tcl keeps a completely > separate 10 MB copy in each and every thread. What you really want is > to just have a single read-only 10 MB copy of all those Tcl proc > definitions, and have all 1000 otherwise completely independent Tcl > interps use those same procs. _RIGHTO_ > > > Zoran, have you talked to Jeff Hobbs about this? He has mentioned > possibly adding "interp cloning" and other sorts of related stuff on > the AOLserver list before. I understand that the compiled Tcl byte > code is somehow specific to the interpretor where it was compiled, so > it doesn't (currently) work to somehow have just one copy that you use > from multiple interps in multiple threads. But perhaps there's some > good way to improve that... No go. I know about that work already. It was done I believe for Cisco as contract-work and is living in Tcl CVS under some branch. The problem is: this is just the single-thread interp-clone. Nothing that can be shared. Since some years I've been trying various approaches how to tackle this problem but I really found no realy good and universal way. I believe there isn't one, after all those years. I will try just this one more idea with unknown-overloading and dispatching unknown command to a battery of preloaded interps living in different threads. Although not 100% transparent (people must code with couple of assumptions) I think it is the most one can do with Tcl. And, I do not think this will improve over time. Hopefully I will soon find piece of mind with this issue and stop going on other people's nervers and saturate email lists :-) Thanks for following so far! 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
Re: [naviserver-devel] ns_perm module bug fix
patched, submitted. Thanks
Daniel Stasinski wrote:
> Here is an interesting one that has been broken since AOLserver 4.0.
>
> In hosts.allow, you can use either a full or partial hostname, or
> ipaddr/netmask. Not all work.
>
> 192.168.0.10/255.255.255.255 <- Gives error "Invalid address or
> hostname "192.168.0.10". should be ipaddr/netmask or hostname"
> 192.168.0.10/255.255.255.0 <- This fixes the above -BUT- it allows in
> the whole class C, which may not really be what is wanted.
> bob.someserver.com <- this works (though haven't looked deep enough
> to see if it does sanity check on forward + reverse lookup to
> guarantee it is really the right host)
>
> The error is caused by inet_addr() returning INADDR_NONE on
> 255.255.255.255 . Using inet_aton() resolves this issue. A patch to
> nsperm.c at around line #739 follows:
>
> *slash = '\0';
> if (inet_aton(net, &ip) == 0 || inet_aton(slash+1, &mask) == 0) {
> Tcl_AppendResult(interp, "invalid address or hostname \"",
> net, "\". " "should be ipaddr/netmask
> or hostname", NULL);
> goto fail;
> }
>
> Daniel
>
--
Vlad Seryakov
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
-
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
Re: [naviserver-devel] moonshadow
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
Re: [naviserver-devel] moonshadow
On 10.05.2008, at 06:13, Andrew Piskorski wrote:
> On Fri, May 09, 2008 at 06:06:05PM +0200, Vasiljevic Zoran wrote:
>
>>> I saw somewhere that Lua can have global and per-thread state
>>> and that you can provide your own locking primitives they use
>>> to lock their own code, but I haven't dig deeper there...
>>
>> Damn again. This is a global lock that serializes everything.
>> A no go :-(
>> Same applies to others (Ruby, Phyton, Perl).
>
> Zoran, are you SURE? Because from what I've read about Lua, it does
> NOT have any sort of single global lock limiting true parallelism to
> one cpu/core at a time the way Python and Ruby do. Lua's default
> behavior is coroutines cooperatively multitasking on just a single
> cpu, but AFAIK the Lua implementation is not inherently limited to
> that.
Coroutines are something similar, (purists outthere, note: _similar_)
to Tcl event loop in terms that they work on a single processor.
This is not real MP multithreading that we need in order to scale.
From the programing perspective, they are indeed very interesting
because they don't force me into the "event-loop" shoe. I have
nothing against event-loop. It is just that it is really targeted to
a GUI type of apps.
I was greping to "lua_lock" calls arround the code and found mostly:
something () {
lua_lock(L);
//...
lua_unlock(L);
}
OK, this must _not_ mean they are absolutely serialized, but it
really appears to me like that on the first glance.
What I plan to do is go to Lua developers and ask couple of
questions...
>
>
> Your application clearly wants to use many thousands of stateful
> lightweight processes. AFAIK Lua and especially Erlang both support
> that out of the box. Do you ALSO need to run 2 or 8 or more of those
> threads in parallel (at the exact same time) on a single multi-cpu
> server? Recent versions of Erlang definitely support that. I'm not
> sure whether or not Lua supports that out of the box, but it may be
> feasible to make it work.
Yep, Erlang is something that looks very good as well. I just stumbled
across that yesterday. Clever, clever... still I have to see how
they works internally and what are the gotchas of their message-passing.
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
