[Mono-list] Re: Calling back from unmanaged code to managed code.

[Jonathan Pryor]

On Fri, 2004-12-10 at 19:02 +0000, Gregory Bowyer wrote:
> Paolo Molaro wrote:
> > We could easily remove this assert and instead add the code to setup
> > the thread to execute managed code. This won't solve the whole issue,
> > though: the GC needs to know about the thread and its stack limits or
> > it won't work correctly.
> > There is also the issue of deciding which application domain should be set
> > for the new thread. We should probably add a call to a function that does
> > all this setup to the wrapper methods used to go from unmanaged to
> > managed code.
> > 
> > lupus
> > 
> If i am reading this correctly, is the lack of support for unmanaged 
> code in mono a case of three incomplete features namely:
> 	1) Lack of Code access security stuff
> 	2) Bits of monos internal setup
> 	3) GC "pinning" and stack issues

To simplify greatly on Francis Brosnan Blázquez's response:

1)  No, Code Access Security has nothing to do with it
2)  Yes, it has to do with Mono's internal requirements, mostly from...
3)  The GC has it's own requirements.

> If so is it that difficult to add this feature to mono (say once the 
> work on code security is finished)

It's not so much difficult, as questionable.  Questionable as in,
"should we do this?".

There are two requirements/changes lupus mentioned:

1.  The native delegate should marshal the thread into the correct 
    AppDomain.  This probably wouldn't be too difficult (says the guy
    who hasn't done *any* runtime hacking).

2.  Setup/initialize non-mono threads so that mono can use them.  This
    includes determining the stack information so that the GC can 
    properly trace the entire GC heap.

(2) is the problematic requirement.  Should mono "take over" all threads
that enter mono?  *Can* mono do that?  (I don't know if it's possible to
get the stack size from the pthreads API.)  Taking over any thread that
enters mono's runtime is questionable, at best -- these may be threads
created by Wine, or Xine, or Evolution, or...  Altering them to make
them suitable for use by mono may be a questionable tactic, at best.

A better approach is what mono already requires -- all threads that used
by mono should call mono_thread_attach before entering or being used by
mono.  Unfortunately this requires partitioning your application so that
non-mono threads don't call into mono, directly or indirectly, but this
is probably the only usable solution.

 - Jon