[Mono-dev] Marshal.GetFunctionPointerForDelegate and non-mono threads

[Alan]

Do you see these issues when running with the soft debugger attached?
If so, that was a bug which was fixed a few days ago. If you're seeing
the issue without the debugger, a small testcase would be great for
figuring this out.

Alan

On 28 January 2013 18:42, sebastian <sebastian at palladiumconsulting.com> wrote:
> We run a program under mono which uses a 3rd party C++ library. Mono is
> responsible for running the application, that is, we are not using the
> mono_embed API, but rather just PInvoke to talk to the C++ library.
>
> This library has some callbacks which we subscribe to using
> Marhsal.GetFunctionPointerForDelegate. However we get exotic concurrency
> problems (seg faults, inexplicable stacktraces) when we use it. We only get
> these errors when the callback is made from a thread which was not started
> by us.
>
> I know that when embedding mono, i.e. with C++ in the driver's seat, threads
> must be registered with mono using mono_thread_attach. However that would be
> a funny thing for us to do, since we're not launching mono ourselves and
> would have to do some exploration to find all the right pointers.
>
> Does the code in GetFunctionPointerForDelegate emit a managed wrapper that
> takes care of this detail? Once we are called back on this foreign thread,
> there's no telling what or how much .NET code will run on it, and it
> presumably needs to be properly registered with the garbage collector. I
> looked at the code in mono_marshal_get_managed_wrapper and didn't see
> anything obviously related to threading, but I imagine it'd be taken care of
> at a lower level in any case.
>
> We could easily be convinced the bugs we saw were GC or threading related,
> as they could only be explained by corruption of things that shouldn't be
> corruptible, like reflection and array bounds.
>
> Or is there additional code or attributes we should be using to ensure
> correct operation?
>
> Thanks,
> Sebastian
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>