Are you doing something like this?
for(int i = 0; i<1000; i++)
{
System.Threading.ThreadPool.QueueUserWorkItem(new
System.Threading.WaitCallback(PostData),state);
}
Don't forget that you fill a queue. If thread pool execution rate is smaller
than task submission you can have a problem
Use the CLR memory profiler. It does a good job of showing you what's
chewing up memory. That is, if it is instances of managed classes. If
you're leaking unmanaged memory, it's more difficult to diagnose.
-- arlie
-Original Message-
From: Unmoderated discussion of advanced .NET topics
Sent: Monday, June 07, 2004 1:49 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] ThreadPool.QueueUserWorkItem Memory
Problems
WaitCallback class ?
Are you creating a "WaitCallback" class for each queue
item?
--- Paul Johansen <[EMAIL PROTECTED]>
wrote:
> I
EMAIL PROTECTED] On Behalf Of Sam Ang
Sent: Monday, June 07, 2004 1:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] ThreadPool.QueueUserWorkItem Memory
Problems
How about setting your state object to null at the end
of your PostData?
sam
--- Paul Johansen <[EMAIL PROTECTED]>
wrot
WaitCallback class ?
Are you creating a "WaitCallback" class for each queue
item?
--- Paul Johansen <[EMAIL PROTECTED]>
wrote:
> I have implemented a multithreaded solution where I
> am calling
> ThreadPool.QueueUserWorkItem and I am passing both
> the WaitCallback
> class (using a method called
How about setting your state object to null at the end
of your PostData?
sam
--- Paul Johansen <[EMAIL PROTECTED]>
wrote:
> I have implemented a multithreaded solution where I
> am calling
> ThreadPool.QueueUserWorkItem and I am passing both
> the WaitCallback
> class (using a method called PostDa
