Am 11.04.2007 um 20:45 schrieb Peter Amstutz: > [...] > On a related note, I started thinking a lot about user > threads/microthreading/continuations etc in part from reading a couple > of developer blog entries on how Linden Labs acomplished it in their > server. They have an interesting challenge (which we will eventually > also have to deal with) which is that they need to support many > thousands of scripts running simultaneously on a simulator, and the > scripts come from untrusted sources that can do obnoxious things like > spin in an infinite loop and never return. Operating system threads > arn't suitable due to overhead (and possibly also due to > synchronization > requirements with the physics simulation) so it has to be a user-level > thread strategy. However, users can't be trusted to have their code > ever yield (or even ever end). So, they force the issue. The scripts > are compiled for the .NET virtual machine, but before they are allowed > to run, a gatekeeper inserts explicit yields into the bytecode at > strategic points (branching points being the obvious target, if I > had to > guess). This results in each script periodically checking to see > if it > has run out its timeslice, and when that happens it explicit yields to > the next thread without the need for preemptive scheduling. > I thought that the coroutine stuff applied "trusted" code only - after all, when you cross the border to untrusted code, you have to pass control over to whatever virtual machine executes it, and hope for the best. In the most general case, this virtual machine might use a different threading model or may not even *have* threads (shell script?). Changing arbitrary kinds of script code on the fly is bound to be difficult, error prone and time consuming. Modifying all VMs to support context switching is even more unrealistic. Usually people only have a standard perl/python/lua/xyz installation. LL has the advantage that people only use ONE scripting language, running on ONE VM - under their control.
Regards, Karsten Otto (kao) _______________________________________________ vos-d mailing list [EMAIL PROTECTED] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
