[Mono-bugs] [Bug 75119][Blo] New - thread/gc issue ...

[bugzilla-daemon at bugzilla.ximian.com]

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 michael at ximian.com.

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: mono-bugs at ximian.com                            
+ReportedBy: michael at ximian.com               
+QAContact: mono-bugs at ximian.com
+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. ;-)