AppDomains

Ok, cool :-).  I've got NullReferenceException detection using signals
working and they will only consider SEGVs NullReferenceExceptions if they
occur in managed code.  Seems to be stable and exceptions are still handled
correctly.  It might be something to consider for the future.  Anyway, with
that experiment over, I might move over to (slowly -- my free time is
limited at the mo) getting AppDomains working.

It will require some changes to the "external" API for the engine.  For
example, ILExecProcessGetMain() will no longer be relevant because an
AppDomain/ExecProcess shouldn't have the concept of a "main thread".  Any
thread can execute within the context of any AppDomain.

It might also be helpful (but not vital) if we could rename ILExecProcess to
ILExecAppDomain.

Applications using the engine API will need to be changed.  Instead of
creating an ILExecProcess, ILExecProcessGetMain and then calling the entry
point, I imagine it would have to be something like this:

ILExecThread *thread;
ILExecAppDomain *domain;

/* Create an AppDomain */
domain = ILExecAppDomainCreate(stacksize, cachesize);

/* Register the current thread for managed execution using domain
   to get the default config for stacksize etc */

thread = ILThreadRegisterForManagedExecution(domain, ILThreadSelf());

/* Load assembly into AppDomain and execute from there....
   The thread will execute in the context of "domain" until
   ILExecAppDomainExecuteAssembly exits. */

ILExecAppDomainExecuteAssembly(domain, "test.exe");

/* Unload the AppDomain. */
ILExecAppDomainUnload(domain);

/* Wait for AppDomain to unload */
ILExecAppDomainWaitForUnload(-1);

The API won't require threads in the sense that on single threaded systems,
you can register the current and only thread to run managed code and have it
enter a domain; you aren't forced to create or use a whole new thread to use
a domain.  Multithreaded apps that embed PNET should probably create a whole
new thread (using ILThreadCreate) in which to call
ILExecAppDomainExecuteAssembly just in case the assembly tries to wait on
the "main" thread (I highlighted this scenario in my last email).  On
multithreaded systems, ILExecAppDomainUnload will return immediately but the
AppDomain won't unload until all threads executing within that domain end or
stop executing within that domain.  If the "test.exe" assembly in the above
program creates no threads and doesn't try to "join" the main thread, then
the above program will run to completion without halting on both threaded
and multithreaded systems.

I think there needs to be a lot more design needed but I guess that's what
IRC and mailing lists are for :-).  From what I've already thought about, I
think the new design will be *HEAPS* simpler than the current system.
Because threads and AppDomains have been separated (AppDomains becoming
hosts rather than owners of threads), ILExecAppDomainUnload and others will
be simpler and easier to understand than the current equivalent
implementations.  Also, once AppDomains and AppDomain unloading has been
implemented, the ability for "ilrun" to safely exit if a "naughty" thread
won't abort and exit the primary AppDomain will be possible since the
unloading is done within another thread.

If you give me an ok, I'll start implementing all this.

Regards,

^Tum

> -----Original Message-----
> From: Rhys Weatherley [mailto:[email protected]]
> Sent: Thursday, 20 May 2004 12:00 a.m.
> To: Thong (Tum) Nguyen
> Subject: Re: SIGSEGV handling
> 
> On Wednesday 19 May 2004 08:38 pm, Thong (Tum) Nguyen wrote:
> 
> > I see that there are methods for internal and p/invoke calls but it
> doesn't
> > look like the ILMethod itself is pushed onto the CVM stack by
> cvm_setup.c
> > which means I can't setup an ILClassFrame  frame for the internal call
> to
> > track internal calls.
> 
> An ILCallFrame is created to save the current context when a new method is
> called.  It does not hold information about the currently executing
> method.
> That is kept in the ILExecThread object instead.
> 
> The ILMethod that you are looking for is in the "method" variable within
> the
> interpreter.  Prior to a native function callout, it is copied into the
> ILExecThread object by COPY_STATE_TO_THREAD.
> 
> Alternatively, check out "ILExecThreadStackMethod" in "engine/thread.c",
> which
> shows how to find the method "num" items up the stack, with zero
> indicating
> the currently-running method.
> 
> Cheers,
> 
> Rhys.