[Mono-bugs] [Bug 75239][Nor] Changed - Processes creating threads have long pauses.

[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 jan.oravec at 6com.sk.

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

--- shadow/75239	2005-07-05 16:28:48.000000000 -0400
+++ shadow/75239.tmp.20406	2005-08-28 10:38:29.000000000 -0400
@@ -10,12 +10,13 @@
 Component: io-layer
 AssignedTo: dick at ximian.com                            
 ReportedBy: vguzev at yandex.ru               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
 URL: 
+Cc: jan.oravec at 6com.sk,matt.hargett at logiclibrary.com
 Summary: Processes creating threads have long pauses.
 
 Description of Problem:
 DNS.GetHostName() sometimes hangs on in my programs! When I tried to find 
 a small example why does it happen I found another one error that's 
 connected with DNS.GetHostName and multithreading as I think...
@@ -1634,6 +1635,45 @@
 ------- Additional Comments From bmaurer at users.sf.net  2005-07-05 16:28 -------
 The segfaults and hangs are now fixed in svn. The only remaining
 problem is that the test case frequently pauses. From what I can tell,
 this seems to be an issue in the io-layer. This is no longer major
 though because the process is always able to go forward within a few
 seconds.
+
+------- Additional Comments From jan.oravec at 6com.sk  2005-08-28 10:38 -------
+Frequent pausing is caused by destroying of the threads.
+The following code runs almost forever until WriteLine is reached:
+
+public class M
+{  
+  public static void Main()
+  {
+    Thread[] x=new Thread[1000];
+    ThreadStart ts = new ThreadStart(thr);
+ 
+    for(int i=0; i<1000; ++i)
+      (x[i]=new Thread(ts)).Start();
+    
+    for(int i=0; i<1000; ++i)
+      x[i].Join();
+
+    Console.WriteLine("Finished");
+  }
+   
+  private static void thr()
+  {
+//    Thread.Sleep(Timeout.Infinite);
+  }
+}
+ 
+If you uncomment the Sleep line, everything is fast.
+
+
+I have tried to find out more about that. strace shows a thousands of
+semop() system calls per thread when it is finishing:
+
+[pid 21931] semop(0, 0xb78f73ea, 1 <unfinished ...>
+[pid 21931] <... semop resumed> )       = 0
+
+I think that this is major fault, because with ~100 short-term threads
+running system starts to be very inresponsive.
+