[Mono-devel-list] Embedding Mono in a Virtual World

[Paolo Molaro]

On 02/11/05 Jim Purbrick wrote:
> I think this approach generalises to the continuation
> based approach used by PicoThreads in Java[1]: you
> need to build chains of continuations on the heap that
> you can switch between to switch threads, something
> that Dan Sugalski suggests is really inefficient and
> one of the reasons you might want to use Parrot
> instead of the JVM or Mono[2].

Except Parrot is still not suitable to develop any of this stuff:-)
Anyway, as I said it will be slow: with mono 2.0 heap
allocations should become much faster, so, depending
on your timeframe it may not be so bad.

> Fibers are cooperatively scheduled light weight
> threads in Win32[3]. The core of the approach boils
> down to:
> 
> schedule()
> {
> saveCLRLogicalThreadState(currentThreadState);
> switchOSFiber(nextFiber);
> restoreCLRLogicalThreadState(nextThreadState);
> }
> 
> Which is used to keep the logical managed thread state
> and fiber in sync. They had some problems with
> exceptions using this approach and the logical thread
> save and restore methods maybe something that's only
> available in Rotor.

I don't see us implementing any of the support needed for this,
though of corse we would accept good patches to do it.
Personally, I don't think the complexity it introduces is
worth it for the default mono behaviour (the good thing about mono
is that you could write the support and use your own build with
it enabled to run your app:-).

> > It should be pretty safe if you inject in the user
> code checks for a
> > global var that signals the event
> 
> Couldn't I just call Thread.Suspend from the main
> thread after the timeout? 

Yes, but that coiuld lead to deadlocks, since the script might
hold a lock that another script or your engine needs to acquire
or worse, it may have a lock in the mono runtime. We'll be
putting some protection against the latter issue, in the future, but
until then, it's better to make the script call Suspend, because
you can ensure it's in a safe place wrt your engine (and
calling Suspend from managed code on the current thread is safe
wrt the mono runtime state).

> > The Suspend method is marked obsolete in 2.0,
> > because of the potential for deadlocks, but using it
> this way should
> > be safe.
> 
> Will I still be able to use this approach with future
> versions of Mono then?

Obsolete means the call will still work, but you'll have
a warning when compiling (if you use a C# compiler or the like).

> > Since most of the scripts should terminate within
> > the timeout, if I understood correctly, you should
> just have a number
> > of threads created as many as the slow scripts 
> 
> Yes, as all bar one of the threads would be suspended
> that presumably wouldn't cause any context switching
> problems. The only problem would be that each
> suspended thread would still have a full OS thread
> stack, so might burn a pile of memory.

The Mono 2.0 API already implements the calls to specify your 
own thread stack size: the minimum is 128 KB IIRC, but this will
allow you to have 100 'slow' scripts in 13 MBs of memory.
If that's enough for your requirements, this could be a good approach.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better