[Mono-bugs] [Bug 53078][Nor] Changed - Thread not disposed if Start not called

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Tue, 20 Jan 2004 08:27:13 -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 derek.mcumber@datamtnsol.com.

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

--- shadow/53078	2004-01-20 08:26:04.000000000 -0500
+++ shadow/53078.tmp.19182	2004-01-20 08:27:13.000000000 -0500
@@ -2,13 +2,13 @@
 Product: Mono/Class Libraries
 Version: unspecified
 OS: All
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Normal
 Component: CORLIB
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: gonzalo@ximian.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
@@ -44,6 +44,47 @@
 
 
 ------- Additional Comments From derek.mcumber@datamtnsol.com  2004-01-20 08:26 -------
 Created an attachment (id=6470)
 Declare thread that creates 1 Meg buffers
 
+
+------- Additional Comments From derek.mcumber@datamtnsol.com  2004-01-20 08:27 -------
+Thanks for the quick reply.
+
+I think there may be two issues.
+
+The one I am trying to solve is when
+    XSP calls
+        MonoWorkerRequest.ProcessRequest, which calls        
+            HttpRuntime.ProcessRequest()
+
+A thread is created in the threadpool and it runs, but then stops
+at the ~Thread() finalizer and waits for the XSP.exe to shutdown
+before finalizing.
+
+In a web environment, the finalizer needs to be run when the scope
+has left.  Subsequent calls of 'ProcessRequest' read in a new
+version of XSP.exe and the System.Web.dll because the previous
+copy is blocked waiting for finalization.
+
+If you run XSP for about 20 page requests on Windows you will run
+out of RAM and get GC Heap Errors before Mono.exe fails.
+
+In trying to recreate the problem, Gonzolo may have found some other
+issues, but my original question for is this:
+
+How can I call ~Thread() either in Threads.cs, ThreadPool.cs or
+gc.c at a moment when it has completed running and is holding
+desparately needed resources?
+
+Thanks for all your help.  Here is an example that holds up
+50Meg of RAM when compiled with mono (look at Task Manager or
+ps -eaf) but with csc.exe and MS.NET runtime, it cleans up
+the threads and only 6Meg of RAM is used after completion.
+
+I created a version of corlib.dll that prints Console.WriteLine
+statements in ~Thread() and have verified they do not run until
+the main thread is shut down.
+
+Derek
+