[Mono-bugs] [Bug 81735][Wis] Changed - Thread.Join() has issues.

[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 robertj at gmx.net.

http://bugzilla.ximian.com/show_bug.cgi?id=81735

--- shadow/81735	2007-05-25 12:56:06.000000000 -0400
+++ shadow/81735.tmp.1724	2007-05-25 18:13:36.000000000 -0400
@@ -1,14 +1,14 @@
 Bug#: 81735
 Product: Mono: Class Libraries
 Version: 1.0
-OS: 
+OS: unknown
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Wishlist
 Component: CORLIB
 AssignedTo: cjcollier at colliertech.org                            
 ReportedBy: cjcollier at colliertech.org               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
@@ -19,6 +19,24 @@
 fix this...
 
 ------- Additional Comments From cjcollier at colliertech.org  2007-05-25 12:56 -------
 Created an attachment (id=19317)
 exercises the bug
 
+
+------- Additional Comments From robertj at gmx.net  2007-05-25 18:13 -------
+I cannot reproduce this with SVN HEAD on amd64 (SMP machine).
+
+Note that blocking like this from inside a timer callback will
+consume all thread pool threads.
+It shouldn't crash, though, but it will definitely cause nasty
+deadlocks in other parts of the runtime that rely on async calls.
+
+If you can predict how many timer calls would potentially block,
+you could raise the number of threads in threadpool using the
+environment variable MONO_THREADS_PER_CPU (see mono(1)).
+
+If you cannot predict them, the only solution is to employ a
+bunch of worker threads that get their work from the timer
+callbacks as fast as possible (w/out long living locks).
+
+