This is quite an issue for me when doing debugging for async delegate call
(i.e., using BeginInvoke).
Note this is NOT Control.BeginInvoke, which runs on the thread creates the
control.
According to MSDN:
If the BeginInvoke method is called, the common language runtime (CLR) will
queue the request and return immediately to the caller. The target method
will be called on a thread from the thread pool.
SO it comes to Q1: is this thread pool the same one as
System.Threading.ThreadPool? What if I have used System.Threading.ThreadPool
to its full capacity and there is no more free thread available there? Will
the BeginInvoke be blocked there? If so, the design of async delegate has
problem.

Also, since thread and thread pool is already there in the framework, what
is the necessity of the existence of asycn delegate then? Or what is the
difference between them?

Thanks in advance. I have been puzzled by above questions for quite some time.

Fluxray <Flux***@discussions.microsoft.com> wrote:
Yes.

Well, it will wait until a thread becomes available. The thread pool is
designed to run short-lived tasks. Personally I think it's a pity that
there's just one thread-pool, rather than allowing users to create
their own instances which they can control themselves (e.g. by only
using one thread-pool for a certain type of task, leaving the system
thread-pool free).

There are often multiple ways of accomplishing the same thing. It's
often easier to call BeginInvoke, passing in the appropriate
parameters, than to call QueueUserWorkItem. Other times,
QueueUserWorkItem is simpler, if you need a callback but don't need to
pass in more than one piece of state.

I see Jon already answered, but I'll second his answer: Yes, it's the same
thread pool.

You're screwed.

To help with this a little bit, the next service pack to .NET will increase
the default size of the thread pool. This won't solve the problem, but it'll
make things a bit better.
http://www.bluebytesoftware.com/blog/PermaLink,guid,ca22a5a8-a3c9-4ee8-9b41-667dbd7d2108.aspx

For Server applications, I recommend against using the thread pool. It leads
to too many issues. The problem becomes especially acute if you're doing I/O
bound synchronous processing on thread pool threads - for example, a
database call. In these cases, your server will completly deadlock, and
you're stuck restarting the process.

I've blogged about this, and the related issues, here:
http://www.coversant.com/dotnetnuke/Default.aspx?tabid=88&EntryID=8

Joe Duffy (at the time, he was in charge of Concurrency for .Net at
Microsoft) has also written some great pieces on this problem:
http://www.bluebytesoftware.com/blog/PermaLink,guid,fe3434c7-b3b7-42c8-9267-df996c9c222a.aspx
http://www.bluebytesoftware.com/blog/PermaLink,guid,ed78e4f1-fcaa-47a8-920b-804fe217c9d3.aspx

Thanks very much, Jon and Chris. Chris I am going to read those links and
thanks again for that.

Actually we are building a server part of whose service is to transfer files
to clients. Since thread pool provided ways to set its maximum thread, we
just use it to control the server load.

But after reading your explanations, I just found what we doen is a
potential time bomb. Suppose there are many files in the threadpool queue
already, and if we have any asynchronous delegate calls (Or something else
using the thread pool) requires a fast response, then the things will really
get screwed up.

Jon you are right that it is a pity to have only one threadpool. I also feel
this is something like a defect by design. If threadpool is open for user to
use, then async delegate shall not use it in a hidden way which many of the
developers cannot see.

I wonder if there is any other stuff also sharing the threadpool?

Hungarian Notation Vs Pascal Notation?
Simple problem: Why does this cause a massive memory leak?
How to handle this exception?
how to control UDP sending Speed?
Save the state of a SplitContainer