Thanks for confirming Rodrigo. On Jan 29, 2013, at 6:43 AM, Rodrigo Kumpera <[email protected]> wrote:
> GetFunctionPointerForDelegate does produce a wrapper that checks if the > thread is attached > before entering managed. > > > On Mon, Jan 28, 2013 at 10:00 PM, <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 > >> [email protected] > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >> > _______________________________________________ > Mono-devel-list mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/mono-devel-list >
_______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
