You can create your own thread and it will run independantly of any thread
that's being used by ASP.NET. So your request will not be at all influenced
by the secondary thread (barring any other code you write).
As for creating a thread for every request, you are correct that this has
the potential to get out of hand. Each thread you create is an expensive
resource and you don't want this to grow without bound.
I'd suggest two things: 1) Checking out Mike Woodring's thread pool implementation[1].
This is a thread pool you can use from within ASP.NET to prevent from creating
too many of your own threads. Mind you, you probabaly don't want to use the
..NET thread pool, as those are threads that are being used by ASP.NET so
using up those will affect ASP.NET's ability to process requests. 2) Check
out Fritz's async ASP.NET page article. This covers some of these topics.
[1]
http://www.bearcanyon.com/dotnet/#threadpool
[2]
http://msdn.microsoft.com/msdnmag/is...g/default.aspx
-Brock
DevelopMentor
http://staff.develop.com/ballen Hi
I am considering spawning a background thread to perform a long
running task in my asp.net application and I was hoping someone could
shed some light on several issues for which I have not been able to
find solid answers.
Will the spawned thread be terminated prematurely when the originating
request thread is returned to the thread pool or the worker process
recycles? If it is terminated when the request completes, why have a
background thread at all? Why not simply redirect the user without
terminating the execution of the current request? If it isn't, then
it is conceivable that it could serve a similar request which would
then yet create another thread and I could end up with a large number
of threads. Will these threads impact negatively (other than general
server load) on other requests? If the thread is terminated when the
wp recycles, how can background threads be used reliably?
James
(threading noob)