Thread won't start?

[Microsoft]

I'm trying to use threading for the first time and can't get it to work.

(VB)

In the page I've got:

Sub Page_Load( sender As Object, e As EventArgs )
dim o as new Example.Test
o.CreateThread()
End Sub


and in the Example namespace:

Public Class Test

Public Sub RunJob()
While True
WriteToLog( DateTime.UtcNow )
Thread.Sleep( 1000 * 10 )
End While
End Sub

Public Sub CreateThread()
Dim t As New Thread( AddressOf RunJob )
t.Start()
HttpContext.Current.Response.Write( t.ThreadState )
End Sub

End Class



The response is 'Unstarted' (unless I set the priority of the new thread to
AboveNormal or Highest, in which case it's 'Stopped') and nothing gets
written to the log file. If I call o.RunJob() instead of o.CreateThread() on
page loading then that routine works as I expect, i.e. the datetime is
written to the log file every 10 seconds until the request timesout after 90
seconds.

What am I doing wrong?

 

[Kevin Spencer]

The lifetime of a child thread is limited to the lifetime of the parent
thread. As an ASP.Net Page instance lasts for several milliseconds, your
thread is dying almost immediately, when the Page class is unloaded. Try
loading the class into Session State and spawning the thread from there,
where the object remains persistent. However, do not attempt to write to the
Response from Session State, as there is none. The Response is a member of
the Current HttpHandler.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Everybody picks their nose,
But some people are better at hiding it.

 

[Brock Allen]

When you create your child thread you need to realize that the HttpContext.Current
isn't passed along to the other thread, so as Kevin said, you shouldn't be
accessing any of that information on your secondary thread. Also, once your
thread is started, again as Kevin pointed out, the ASP.NET thread has completed
processing of your page and has sent the result back to the client.

In your secondary thread you should be able to do the loop and write out
to a log file, though. I'd suggest debugging it to see what's going wrong
in your RunJob() method.

 

[Brock Allen]

I'm not sure where you got this information, except perhaps you're confusing
this with other environments.

The lifetime of a child thread is limited to the lifetime of the
parent thread.

This is not correct. If a parent thread is terminated it does not implicitly
affect a child thread.

As an ASP.Net Page instance lasts for several
milliseconds, your thread is dying almost immediately, when the Page
class is unloaded.

ASP.NET threads are not created and terminated for each request nor are their
lifetimes tied to the lifetime of the page (or handler). Threads are are
drawn from the CLR thread pool to execute requests in ASP.NET. Once the request
is done the thread is returned to the CLR thread pool. The thread pool may,
over time, create and destroy threads, but this is based upon load upon the
server. It is not tied to each request and/or page.

 

[Roger Mills]

So all that HttpContext.Current.Cache and
HttpContext.Current.Request.MapPath stuff in the WriteToLog routine isn't
so clever when it's called by the new thread, then . . . !!

Still, should be possible to pass these values as properties of the Test
class.

Thanks for all your help,


Roger

 

[Bruce Barker]

not quite true.

the lifetime of a thread is tied to the process. if the hosting appdomain is
unloaded, an abort request is sent to the thread by the clr

if you use create thread as the example did, a new process thread is
created, a thread is not taken from the clr thread pool. you need to use clr
thread pool api to do this.


-- bruce (sqlwork.com)

 

[Brock Allen]

not quite true.

the lifetime of a thread is tied to the process. if the hosting
appdomain is unloaded, an abort request is sent to the thread by the
clr

I don't think I said anything that contradicts this.

if you use create thread as the example did, a new process thread is
created, a thread is not taken from the clr thread pool. you need to
use clr thread pool api to do this.

I don't believe I said this either. I said:

"ASP.NET threads are not created and terminated for each request nor are
their lifetimes tied to the lifetime of the page (or handler). Threads are
are drawn from the CLR thread pool to execute requests in ASP.NET. Once the
request is done the thread is returned to the CLR thread pool. The thread
pool may, over time, create and destroy threads, but this is based upon load
upon the server. It is not tied to each request and/or page."

The context for this entire description was threads used by ASP.NET to process
requests, not manually created threads.

 

[Kevin Spencer]

Mea Culpa, Brock.

I was indeed confusing this with other environments. I'm afraid I'm not an
ASP.Net specialist, so I misspoke. A Thread spawned by an ASP.Net Page will
indeed outlast the Page thread if the Page thread terminates first.

--
Thanks for keeping me honest!

Kevin Spencer
Microsoft MVP
..Net Developer
Everybody picks their nose,
But some people are better at hiding it.