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

[Rodrigo Kumpera]

GetFunctionPointerForDelegate does produce a wrapper that checks if the
thread is attached
before entering managed.


On Mon, Jan 28, 2013 at 10:00 PM, <sebastian at palladiumconsulting.com> wrote:

> We are not using the debugger.
>
> We're not sure how the library in question creates its threads. We
> don't have access to its source code and it's proprietary. Putting
> together a full repro would be hard.
>
> The callback is a simple function which picks up a logged string and
> sends it to NLog by way of an Rx Subject. That's a lot of moving
> parts, but they all work fine when the callback comes from one of our
> threads.
>
> Am I correct in assuming that the GetFunctionPointerForDelegate should
> automatically register the thread it's called on with mono? I have
> enough facts at hand to call the registration function manually if
> need be, but it would be awkward indeed.
>
> On Jan 28, 2013, at 6:34 PM, Alan <alan.mcgovern at gmail.com> wrote:
>
> > 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
> >>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130129/faafba66/attachment.html>