[vos-d] s5 concurrency (design part 2)

[Karsten Otto]

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)