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

[Peter Amstutz]

On Thu, Apr 12, 2007 at 10:41:40AM +0200, Karsten Otto wrote:

> 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.

The point of the Second Life example was that it has been shown in 
practice that it's possible to implement cooperative multitasking in a 
way that still doesn't allow unscrupulous users to hang the system (at 
least not with naive attacks like going into an infinite loop).  This is 
important, because preemptive multitasking is difficult and generally 
non-portable to implement in userspace; it is the job of the underlying 
operating system to provide multitasking facilities (processes, 
threading).  The problem for VOS is that these facilities are probably 
too heavyweight for the number of simultaneously executing actors that 
we want to be able to scale up to support.

In the case of LSL I believe that the client compiles the scripts 
locally and just uploads the bytecodes.  It uses the CLI run on the .NET 
virtual machine, and they've been making noises about supporting C# 
(although it may be that LSL uses a restricted subset of codes that are 
easier to verify, which would not be the case for C#).  So they are 
doing static analysis and modification on the actual bytecodes to be 
run.

So you're right, it requires targeting a specific virtual machine 
platform, but there's nothing wrong with that.  I'm not suggesting this 
for scripting in general, but for the particular case of mobile code 
(downloaded to the client or uploaded to the server and executed 
automatically) where it is necessaray to provide a constrained, secure 
environment.  A pretty fundamental aspect of security is not being able 
to hijack the host application's computation.

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20070412/423c8303/attachment.pgp