Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=75119 --- shadow/75119 2005-06-02 07:07:03.000000000 -0400 +++ shadow/75119.tmp.9364 2005-06-02 07:07:03.000000000 -0400 @@ -0,0 +1,45 @@ +Bug#: 75119 +Product: Mono: Runtime +Version: 1.1 +OS: +OS Details: +Status: NEW +Resolution: +Severity: +Priority: Blocker +Component: GC +AssignedTo: [EMAIL PROTECTED] +ReportedBy: [EMAIL PROTECTED] +QAContact: [EMAIL PROTECTED] +TargetMilestone: --- +URL: +Cc: +Summary: thread/gc issue ... + +So - I think I ommitted to file this as a bug before - however; it's rather +important for Mono/OO.o + +OO.o is highly threaded, and we can't be compiling it with some funky gc +includes / wrappers. + +Particularly - we get callbacks from UNO which go via a bridge & pop up in +any old random thread :-) + +Anyhow - that makes mono & the GC barf. Here is my shot at a patch. + +It sucks because the stack addr we push is from GC_thread_register_foreign +- we could do better there (of course). It also sucks because once +registered - we don't re-register, or de-register the thread - concievably +you could get a deeply nested -> mono call in a thread, followed by a very +shallow nested one & thus screw yourself wrt. GC. + +Anyhow - IMHO a better approach is to push/pop this particular thread area +on the edge of mono_invoke calls - and to do a comparison to work down the +stack. + +Finally - Paolo wanted to do better wrt. finding the beginning of this +thread's stack; there is a __USE_GNU hack to do that: + +pthread_getattr_np - that we could use at a pinch with pthread_attr_getstack. + +Anyhow - FWIW, this works for me, YMMV, the GC is already a mess etc. ;-) _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
