I have a bit of "login authentication" code that in the event of a server
error, connection error, etc will take a Looooooong time to timeout. I
wanted to redesign it to call the DAL method in a separate thread (easy
enough) w/ a callback for when it's done. The area I'm having trouble with
is once I determine the timeout period has elapsed, how do I kill the thread
safely?
I asked a threading question here awhile ago and some kind soul pointed me
to Mr' Skeet's great articles. I learned a lot, but apparently not enough
to handle this problem. Jon suggests in his articles that you check a flag
"stopping" to determine if the user has requested the operation be
cancelled, but this requires you to have the opportunity to evaluate the
value of "stopping" - in my case, I make a call to DAL.AuthenticateUser()
and if that method has trouble... well, my execution on the worker thread
sits there waiting for it to return. no chance to check if the timeout
monitor has set "stopping" true or the user has pressed cancel.
I must be thinking about this wrong. As I type this, it seems like my
problem is the main reason people use threads ;0)
I'm trying to do something like this:
User clicks the "Login" button on the form.
Form click event handler calls my AuthMgr.AuthenticateUser(string username)
method
AuthMgr.AuthenticateUser(string username) starts new thread and passes
DAL.AuthenticateUser(string username) as the proc
AuthMgr.AuthenticateUser(string username) starts another thread to monitor
the time elapsed and fire an event (or make a method call) when that happens
at which point I would want to cancel the thread that is servicing the
DAL.AuthenticateUser() method.
problem is, the call to DAL.AuthenticateUser() is hung up on a
DbConnection.Open() call or a DataAdapter.Fill() method and I can't cleanly
kill the thread.
I hope that makes sense to someone out there that has a little time to shed
some light on this problem for me.
Thanks for reading,
Steve