[Mono-bugs] [Bug 73366][Maj] New - XplatUIX11 cannot handle concurrency in GDI calls.

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Fri, 4 Mar 2005 16:46:47 -0500 (EST)

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 4lw0e0402@sneakemail.com.


--- shadow/73366	2005-03-04 16:46:47.000000000 -0500
+++ shadow/73366.tmp.14459	2005-03-04 16:46:47.000000000 -0500
@@ -0,0 +1,36 @@
+Bug#: 73366
+Product: Mono: Class Libraries
+Version: unspecified
+OS: All
+OS Details: (all operating systems where the X11 XPlatUI driver is used)
+Status: NEW   
+Priority: Major
+Component: Windows.Forms
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: 4lw0e0402@sneakemail.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+Summary: XplatUIX11 cannot handle concurrency in GDI calls.
+Description of Problem:
+  Windows requires that all calls related to windowing objects be done from
+  the same thread (this is an even stricter requirement than
+  synchronization). However, it does not require that for GDI calls. Any
+  user thread can, at any time, obtain a GC to any device and start working
+  with it. When mono's winforms are running under X11, the underlying
+  library is Xlib. This ends up being the transport for all GUI related
+  stuff, including System.Drawing calls related to windows. By default,
+  Xlib cannot handle concurrency, and the result is that when a user
+  thread calls Graphics.FromHwnd(Handle) and tries to draw using that
+  Graphics object, Xlib dies with an "unexpected asynchronous message"
+  error. This can be fixed by calling XInitThreads() once before all other
+  Xlib calls. The attached patch does this.
+Steps to reproduce the problem:
+  Without the patch, all GDI+ calls must be done from the windowing thread.
+  To reproduce the problem, display a form, and then attempt to draw
+  directly to its Handle from a secondary thread.