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

[Paolo Molaro]

On 12/12/04 Jonathan Pryor wrote:
> > 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?".

The answer is: yes, we need to implement the support for it.

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

It's not so much the issue of marshaling the thread object: this
belongs to point 2, IMHO.
The issue is to decide what application domain should be used 
when entering the new thread. This also means that the wrapper
method (the method that makes the transition from unmanaged to 
managed code) needs to be much more complex: it needs to do
a domain transition when entering and a domain restore when exiting
(if the domain was changed).

> 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

It's not possible to get the stack info for a thread portably, unless
we started the thread. This is part of the problem.

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

We can make the wrapper automatically call mono_thread_attach(),
but that's just part of the issue.

lupus

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