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

Jim Purbrick jimpurbrick at yahoo.co.uk
Fri Feb 11 11:13:24 EST 2005


 --- Paolo Molaro <lupus at ximian.com> wrote: 
> > The easiest way to represent the information would
> > be to build a stack for each script, but could I
mess
> > with the stack pointer to switch stacks or would I
> > have to emulate a stack using heaps and would that
> > be horribly inefficient?
> 
> Not orrible but not very nice either.

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

> I have no idea what fibers are and how this would
interact
> with the GC and other info the runtime keeps
per-thread.

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.

> Another option you might want to investigate is to
> use Thread.Suspend (). You'd have a control thread
and
> you'd hand out the scripts to execute to a single
worker
> thread and wait for a timeout. If the script didn't
> finish, the thread is suspended and put on a fifo to
be resumed
> later when you decide it's time to do it. Otherwise
the
> timeout is reset and you make the thread execute
another script.
> This is likely an implementation similar to your
> current code.

Yes, this sounds interesting and potentially a good
approach. Once you suspended the thread you'd just
start a new thread to execute the next script before
you resumed the last script.

> The tricky issue here is the exact time you suspend
> and long running script. This is likely to cause
deadlocks if
> not handled carefully.

All the scripts are independent, only communicating
with the engine via library calls, so as long as the
threads didn't suspend duing an interop call, this
should be fine.

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

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

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

[1] www.cs.berkeley.edu/~jmacd/cs262.pdf
[2]
http://www.sidhe.org/~dan/blog/archives/000157.html
[3] http://msdn.microsoft.com/msdnmag/issues/03/09/CoroutinesinNET/default.aspx


	
	
		
___________________________________________________________ 
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com



More information about the Mono-devel-list mailing list