Threading: Stopping, restarting, etc

[Steve]

I'm having a problem with my Thread usage and I think the general design of
how I'm working with them. My UI class calls a method in another class that
does a lot of work. That "worker" class looks something like this(pseudo
code):
class WorkerClass
{
Thread _listenerThread;

public WorkerClass()
{
_listenerThread = new Thread( new ThreadStart(ListenForInput) );
_listenerThread.IsBackground = true;
_listenerThread.Name = "Worker Listener Thread";
}

public void StartTest()
{
// do some quick stuff, then start the listener thread
_listenerThread.Start();
}

private void ListenForInput()
{
// make call to external library that
// won't return until a condition is met
}

public void CancelTest()
{
_listenerThread.Stop();
}
}


That is pretty close to what I have. So, I have a couple issues that I'm
dealing with. If I have run StartTest() once and call it again later (I
handle when it can be called, ListenForInput raises an event when it's done)
the _listenerThread's ThreadState is 'Background' so a subsequent call to
Start() throws an exception.

I figured I was having this behavior because the thread is a member of the
class rather than local to a method, but I need to have it as a member so
that I can cancel it from the UI if a user wishes.

I added some code to the end of ListenForInput() that would call Stop() on
the thread, but that seems dangerous to kill the thread you are running on?
In fact, is it safe for a process to modify ANYTHING about a thread it's
running on? Like priority or ThreadState?

Basically I'm just not sure how to design what I need. The above class is
an accurate model of what I'm after. Most of the threading examples I have
seen online or too simple and don't cover stuff like this.

Thanks for reading, I hope someone has some pointers for me.
-Steve

 

[Larry Lard]

I'm having a problem with my Thread usage and I think the general design of
how I'm working with them. My UI class calls a method in another class that
does a lot of work. [snip]
Basically I'm just not sure how to design what I need. The above class is
an accurate model of what I'm after. Most of the threading examples I have
seen online or too simple and don't cover stuff like this.

Immediately go and read Jon Skeet's Threading pages at
<http://yoda.arachsys.com/csharp/threads>, or if feeling lazy, just the
'Shutting down worker threads gracefully' page at
<http://yoda.arachsys.com/csharp/threads/shutdown.shtml>.

An invaluable resource!

 

[Nicholas Paldino [.NET/C# MVP]]

Steve,

I think you are going about this the wrong way. You should rarely call
Stop on a thread in order to stop processing on it. Rather, you are better
off having some sort of shared variable which the thread will check
periodically to see if it should terminate. If the variable is set, then
the code in the thread will just exit, and the thread will die.

Also, you should create a new thread when you call StartTest, not when
you create your class. You should use a new thread each time. You can
choose to store it on the class level, but the only reason I can see doing
so would be to determine if an operation is running.

Hope this helps.

 

[Steve]

Cool, I found the first link while googling, but the second one about
stopping is interesting. At first glance, it would seem that it's best
suited for an iterative process that will have a chance to check for the
stop flag. My thread makes a call to a function that will not return until
a specific condition is met. So in theory, it could sit there waiting for
days.

I'm not happy with the fact that it operates that way or doesn't have a
timeout parameter, but it's not my library and I can't change it.

John's article gave me more of an understanding, but I'm still not seeing a
clear path how to proceed forward. I will keep reading some more and
experimenting.

Thanks for the post,
Steve

I'm having a problem with my Thread usage and I think the general design
of
how I'm working with them. My UI class calls a method in another class
that
does a lot of work. [snip]
Basically I'm just not sure how to design what I need. The above class
is
an accurate model of what I'm after. Most of the threading examples I
have
seen online or too simple and don't cover stuff like this.

Immediately go and read Jon Skeet's Threading pages at
<http://yoda.arachsys.com/csharp/threads>, or if feeling lazy, just the
'Shutting down worker threads gracefully' page at
<http://yoda.arachsys.com/csharp/threads/shutdown.shtml>.

An invaluable resource!

 

[Steve]

Hi Nicholas,

I agree that I should not create the thread in the ctor, I changed that
after reading your post. I also understand what you mean about the stop
flag being checked, it's like Jon Skeet's article that Larry posted.

My situation is maybe a bit unique in that my thread is stuck in a method
call that can't check for the stop flag. I would like to kill the thread
gracefully, but I'm not sure if I can.

Basically my situation is:
Thread t = new Thread( new ThreadStart(LongMethod) );
t.Start();

private void LongMethod()
{
while(true)
{
//...
}
}


Any other suggestions?

Thanks for the post!
-Steve

Steve,

I think you are going about this the wrong way. You should rarely call
Stop on a thread in order to stop processing on it. Rather, you are
better off having some sort of shared variable which the thread will check
periodically to see if it should terminate. If the variable is set, then
the code in the thread will just exit, and the thread will die.

Also, you should create a new thread when you call StartTest, not when
you create your class. You should use a new thread each time. You can
choose to store it on the class level, but the only reason I can see doing
so would be to determine if an operation is running.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I'm having a problem with my Thread usage and I think the general design
of how I'm working with them. My UI class calls a method in another
class that does a lot of work. That "worker" class looks something like
this(pseudo code):
class WorkerClass
{
Thread _listenerThread;

public WorkerClass()
{
_listenerThread = new Thread( new ThreadStart(ListenForInput) );
_listenerThread.IsBackground = true;
_listenerThread.Name = "Worker Listener Thread";
}

public void StartTest()
{
// do some quick stuff, then start the listener thread
_listenerThread.Start();
}

private void ListenForInput()
{
// make call to external library that
// won't return until a condition is met
}

public void CancelTest()
{
_listenerThread.Stop();
}
}


That is pretty close to what I have. So, I have a couple issues that I'm
dealing with. If I have run StartTest() once and call it again later (I
handle when it can be called, ListenForInput raises an event when it's
done) the _listenerThread's ThreadState is 'Background' so a subsequent
call to Start() throws an exception.

I figured I was having this behavior because the thread is a member of
the class rather than local to a method, but I need to have it as a
member so that I can cancel it from the UI if a user wishes.

I added some code to the end of ListenForInput() that would call Stop()
on the thread, but that seems dangerous to kill the thread you are
running on? In fact, is it safe for a process to modify ANYTHING about a
thread it's running on? Like priority or ThreadState?

Basically I'm just not sure how to design what I need. The above class
is an accurate model of what I'm after. Most of the threading examples I
have seen online or too simple and don't cover stuff like this.

Thanks for reading, I hope someone has some pointers for me.
-Steve

 

[Larry Lard]

Hi Nicholas,

I agree that I should not create the thread in the ctor, I changed that
after reading your post. I also understand what you mean about the stop
flag being checked, it's like Jon Skeet's article that Larry posted.

My situation is maybe a bit unique in that my thread is stuck in a method
call that can't check for the stop flag. I would like to kill the thread
gracefully, but I'm not sure if I can.

Ah, so while waiting you are actually in third party code with no
timeout or way to neatly interrupt? Hmm. Well in that case, maybe hook
to ThreadInterruptedException, and do a Thread.Interrupt when you want
to signal the thread. As I understand it, Thread.Interrupt is much less
rude than Thread.Abort.

 

[Nicholas Paldino [.NET/C# MVP]]

Steve,

I don't see why you can't check for the stop flag. Basically, instead
of checking the while loop for true, check the flag, like so:

// In class.
private boolean continueLoopLock = new object();
private boolean continueLoop;

private bool ContinueLoop
{
get
{
lock (continueLoopLock)
{
// Return the value.
return continueLoop;
}
}
set
{
lock (continueLoopLock)
{
// Set the value.
continueLoop = value;
}
}
}

// In the class.
Thread t = new Thread(new ThreadStart(LongMethod));
ContinueLoop = true;
t.Start();

private void LongMethod()
{
while (ContinueLoop)
{

}
}

Then, when you want it to stop, you just set ContinueLoop to false.

The property is there to make it easier to encapsulate the locking
logic, since you will have two threads accessing this at the same time.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

I agree that I should not create the thread in the ctor, I changed that
after reading your post. I also understand what you mean about the stop
flag being checked, it's like Jon Skeet's article that Larry posted.

My situation is maybe a bit unique in that my thread is stuck in a method
call that can't check for the stop flag. I would like to kill the thread
gracefully, but I'm not sure if I can.

Basically my situation is:
Thread t = new Thread( new ThreadStart(LongMethod) );
t.Start();

private void LongMethod()
{
while(true)
{
//...
}
}


Any other suggestions?

Thanks for the post!
-Steve

Steve,

I think you are going about this the wrong way. You should rarely
call Stop on a thread in order to stop processing on it. Rather, you are
better off having some sort of shared variable which the thread will
check periodically to see if it should terminate. If the variable is
set, then the code in the thread will just exit, and the thread will die.

Also, you should create a new thread when you call StartTest, not when
you create your class. You should use a new thread each time. You can
choose to store it on the class level, but the only reason I can see
doing so would be to determine if an operation is running.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I'm having a problem with my Thread usage and I think the general design
of how I'm working with them. My UI class calls a method in another
class that does a lot of work. That "worker" class looks something like
this(pseudo code):
class WorkerClass
{
Thread _listenerThread;

public WorkerClass()
{
_listenerThread = new Thread( new ThreadStart(ListenForInput) );
_listenerThread.IsBackground = true;
_listenerThread.Name = "Worker Listener Thread";
}

public void StartTest()
{
// do some quick stuff, then start the listener thread
_listenerThread.Start();
}

private void ListenForInput()
{
// make call to external library that
// won't return until a condition is met
}

public void CancelTest()
{
_listenerThread.Stop();
}
}


That is pretty close to what I have. So, I have a couple issues that
I'm dealing with. If I have run StartTest() once and call it again
later (I handle when it can be called, ListenForInput raises an event
when it's done) the _listenerThread's ThreadState is 'Background' so a
subsequent call to Start() throws an exception.

I figured I was having this behavior because the thread is a member of
the class rather than local to a method, but I need to have it as a
member so that I can cancel it from the UI if a user wishes.

I added some code to the end of ListenForInput() that would call Stop()
on the thread, but that seems dangerous to kill the thread you are
running on? In fact, is it safe for a process to modify ANYTHING about a
thread it's running on? Like priority or ThreadState?

Basically I'm just not sure how to design what I need. The above class
is an accurate model of what I'm after. Most of the threading examples
I have seen online or too simple and don't cover stuff like this.

Thanks for reading, I hope someone has some pointers for me.
-Steve

 

[Steve]

My fault Nicholas, I should have been more specific. My LongMethod()
function isn't mine, I can't change it. It's a 3rd party library. I had
said that I can't check for the stop flag, but I didn't say why. Apologies.

-Steve

Steve,

I don't see why you can't check for the stop flag. Basically, instead
of checking the while loop for true, check the flag, like so:

// In class.
private boolean continueLoopLock = new object();
private boolean continueLoop;

private bool ContinueLoop
{
get
{
lock (continueLoopLock)
{
// Return the value.
return continueLoop;
}
}
set
{
lock (continueLoopLock)
{
// Set the value.
continueLoop = value;
}
}
}

// In the class.
Thread t = new Thread(new ThreadStart(LongMethod));
ContinueLoop = true;
t.Start();

private void LongMethod()
{
while (ContinueLoop)
{

}
}

Then, when you want it to stop, you just set ContinueLoop to false.

The property is there to make it easier to encapsulate the locking
logic, since you will have two threads accessing this at the same time.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

I agree that I should not create the thread in the ctor, I changed that
after reading your post. I also understand what you mean about the stop
flag being checked, it's like Jon Skeet's article that Larry posted.

My situation is maybe a bit unique in that my thread is stuck in a method
call that can't check for the stop flag. I would like to kill the thread
gracefully, but I'm not sure if I can.

Basically my situation is:
Thread t = new Thread( new ThreadStart(LongMethod) );
t.Start();

private void LongMethod()
{
while(true)
{
//...
}
}


Any other suggestions?

Thanks for the post!
-Steve

Steve,

I think you are going about this the wrong way. You should rarely
call Stop on a thread in order to stop processing on it. Rather, you
are better off having some sort of shared variable which the thread will
check periodically to see if it should terminate. If the variable is
set, then the code in the thread will just exit, and the thread will
die.

Also, you should create a new thread when you call StartTest, not
when you create your class. You should use a new thread each time. You
can choose to store it on the class level, but the only reason I can see
doing so would be to determine if an operation is running.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I'm having a problem with my Thread usage and I think the general
design of how I'm working with them. My UI class calls a method in
another class that does a lot of work. That "worker" class looks
something like this(pseudo code):
class WorkerClass
{
Thread _listenerThread;

public WorkerClass()
{
_listenerThread = new Thread( new ThreadStart(ListenForInput) );
_listenerThread.IsBackground = true;
_listenerThread.Name = "Worker Listener Thread";
}

public void StartTest()
{
// do some quick stuff, then start the listener thread
_listenerThread.Start();
}

private void ListenForInput()
{
// make call to external library that
// won't return until a condition is met
}

public void CancelTest()
{
_listenerThread.Stop();
}
}


That is pretty close to what I have. So, I have a couple issues that
I'm dealing with. If I have run StartTest() once and call it again
later (I handle when it can be called, ListenForInput raises an event
when it's done) the _listenerThread's ThreadState is 'Background' so a
subsequent call to Start() throws an exception.

I figured I was having this behavior because the thread is a member of
the class rather than local to a method, but I need to have it as a
member so that I can cancel it from the UI if a user wishes.

I added some code to the end of ListenForInput() that would call Stop()
on the thread, but that seems dangerous to kill the thread you are
running on? In fact, is it safe for a process to modify ANYTHING about
a thread it's running on? Like priority or ThreadState?

Basically I'm just not sure how to design what I need. The above class
is an accurate model of what I'm after. Most of the threading examples
I have seen online or too simple and don't cover stuff like this.

Thanks for reading, I hope someone has some pointers for me.
-Steve

 

[Nick Hounsome]

Can you make the method fail or otherwise return some other way?

For example a traditional way to escape from thread blocked on a TCP read is
just to close the socket.

If you can make the 3rd party call return in some way you can use a state
variable to tell the thread that you did it on purpose.

My fault Nicholas, I should have been more specific. My LongMethod()
function isn't mine, I can't change it. It's a 3rd party library. I had
said that I can't check for the stop flag, but I didn't say why.
Apologies.

-Steve

Steve,

I don't see why you can't check for the stop flag. Basically, instead
of checking the while loop for true, check the flag, like so:

// In class.
private boolean continueLoopLock = new object();
private boolean continueLoop;

private bool ContinueLoop
{
get
{
lock (continueLoopLock)
{
// Return the value.
return continueLoop;
}
}
set
{
lock (continueLoopLock)
{
// Set the value.
continueLoop = value;
}
}
}

// In the class.
Thread t = new Thread(new ThreadStart(LongMethod));
ContinueLoop = true;
t.Start();

private void LongMethod()
{
while (ContinueLoop)
{

}
}

Then, when you want it to stop, you just set ContinueLoop to false.

The property is there to make it easier to encapsulate the locking
logic, since you will have two threads accessing this at the same time.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

I agree that I should not create the thread in the ctor, I changed that
after reading your post. I also understand what you mean about the stop
flag being checked, it's like Jon Skeet's article that Larry posted.

My situation is maybe a bit unique in that my thread is stuck in a
method call that can't check for the stop flag. I would like to kill
the thread gracefully, but I'm not sure if I can.

Basically my situation is:
Thread t = new Thread( new ThreadStart(LongMethod) );
t.Start();

private void LongMethod()
{
while(true)
{
//...
}
}


Any other suggestions?

Thanks for the post!
-Steve




in message Steve,

I think you are going about this the wrong way. You should rarely
call Stop on a thread in order to stop processing on it. Rather, you
are better off having some sort of shared variable which the thread
will check periodically to see if it should terminate. If the variable
is set, then the code in the thread will just exit, and the thread will
die.

Also, you should create a new thread when you call StartTest, not
when you create your class. You should use a new thread each time.
You can choose to store it on the class level, but the only reason I
can see doing so would be to determine if an operation is running.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I'm having a problem with my Thread usage and I think the general
design of how I'm working with them. My UI class calls a method in
another class that does a lot of work. That "worker" class looks
something like this(pseudo code):
class WorkerClass
{
Thread _listenerThread;

public WorkerClass()
{
_listenerThread = new Thread( new
ThreadStart(ListenForInput) );
_listenerThread.IsBackground = true;
_listenerThread.Name = "Worker Listener Thread";
}

public void StartTest()
{
// do some quick stuff, then start the listener thread
_listenerThread.Start();
}

private void ListenForInput()
{
// make call to external library that
// won't return until a condition is met
}

public void CancelTest()
{
_listenerThread.Stop();
}
}


That is pretty close to what I have. So, I have a couple issues that
I'm dealing with. If I have run StartTest() once and call it again
later (I handle when it can be called, ListenForInput raises an event
when it's done) the _listenerThread's ThreadState is 'Background' so a
subsequent call to Start() throws an exception.

I figured I was having this behavior because the thread is a member of
the class rather than local to a method, but I need to have it as a
member so that I can cancel it from the UI if a user wishes.

I added some code to the end of ListenForInput() that would call
Stop() on the thread, but that seems dangerous to kill the thread you
are running on? In fact, is it safe for a process to modify ANYTHING
about a thread it's running on? Like priority or ThreadState?

Basically I'm just not sure how to design what I need. The above
class is an accurate model of what I'm after. Most of the threading
examples I have seen online or too simple and don't cover stuff like
this.

Thanks for reading, I hope someone has some pointers for me.
-Steve

 

[Willy Denoyette [MVP]]

Let the third party fix their code, this is all you can do. Calling
Thread.Abort on a thread other than the currently executing thread is BAD,
you don't know what the the thread is actually doing, it's even possible
that he is blocked in unmanaged code, in which case a Thread.Abort won't
help you anyway.

Willy.


| My fault Nicholas, I should have been more specific. My LongMethod()
| function isn't mine, I can't change it. It's a 3rd party library. I had
| said that I can't check for the stop flag, but I didn't say why.
Apologies.
|
| -Steve
|
|
in
| message | > Steve,
| >
| > I don't see why you can't check for the stop flag. Basically,
instead
| > of checking the while loop for true, check the flag, like so:
| >
| > // In class.
| > private boolean continueLoopLock = new object();
| > private boolean continueLoop;
| >
| > private bool ContinueLoop
| > {
| > get
| > {
| > lock (continueLoopLock)
| > {
| > // Return the value.
| > return continueLoop;
| > }
| > }
| > set
| > {
| > lock (continueLoopLock)
| > {
| > // Set the value.
| > continueLoop = value;
| > }
| > }
| > }
| >
| > // In the class.
| > Thread t = new Thread(new ThreadStart(LongMethod));
| > ContinueLoop = true;
| > t.Start();
| >
| > private void LongMethod()
| > {
| > while (ContinueLoop)
| > {
| >
| > }
| > }
| >
| > Then, when you want it to stop, you just set ContinueLoop to false.
| >
| > The property is there to make it easier to encapsulate the locking
| > logic, since you will have two threads accessing this at the same time.
| >
| >
| > --
| > - Nicholas Paldino [.NET/C# MVP]
| > - (e-mail address removed)
| >
| > | >> Hi Nicholas,
| >>
| >> I agree that I should not create the thread in the ctor, I changed that
| >> after reading your post. I also understand what you mean about the
stop
| >> flag being checked, it's like Jon Skeet's article that Larry posted.
| >>
| >> My situation is maybe a bit unique in that my thread is stuck in a
method
| >> call that can't check for the stop flag. I would like to kill the
thread
| >> gracefully, but I'm not sure if I can.
| >>
| >> Basically my situation is:
| >> Thread t = new Thread( new ThreadStart(LongMethod) );
| >> t.Start();
| >>
| >> private void LongMethod()
| >> {
| >> while(true)
| >> {
| >> //...
| >> }
| >> }
| >>
| >>
| >> Any other suggestions?
| >>
| >> Thanks for the post!
| >> -Steve
| >>
| >>
| >>
| >>
| >> "Nicholas Paldino [.NET/C# MVP]" <[email protected]>
wrote
| >> in message | >>> Steve,
| >>>
| >>> I think you are going about this the wrong way. You should rarely
| >>> call Stop on a thread in order to stop processing on it. Rather, you
| >>> are better off having some sort of shared variable which the thread
will
| >>> check periodically to see if it should terminate. If the variable is
| >>> set, then the code in the thread will just exit, and the thread will
| >>> die.
| >>>
| >>> Also, you should create a new thread when you call StartTest, not
| >>> when you create your class. You should use a new thread each time.
You
| >>> can choose to store it on the class level, but the only reason I can
see
| >>> doing so would be to determine if an operation is running.
| >>>
| >>> Hope this helps.
| >>>
| >>>
| >>> --
| >>> - Nicholas Paldino [.NET/C# MVP]
| >>> - (e-mail address removed)
| >>>
| >>> | >>>> I'm having a problem with my Thread usage and I think the general
| >>>> design of how I'm working with them. My UI class calls a method in
| >>>> another class that does a lot of work. That "worker" class looks
| >>>> something like this(pseudo code):
| >>>> class WorkerClass
| >>>> {
| >>>> Thread _listenerThread;
| >>>>
| >>>> public WorkerClass()
| >>>> {
| >>>> _listenerThread = new Thread( new
ThreadStart(ListenForInput) );
| >>>> _listenerThread.IsBackground = true;
| >>>> _listenerThread.Name = "Worker Listener Thread";
| >>>> }
| >>>>
| >>>> public void StartTest()
| >>>> {
| >>>> // do some quick stuff, then start the listener thread
| >>>> _listenerThread.Start();
| >>>> }
| >>>>
| >>>> private void ListenForInput()
| >>>> {
| >>>> // make call to external library that
| >>>> // won't return until a condition is met
| >>>> }
| >>>>
| >>>> public void CancelTest()
| >>>> {
| >>>> _listenerThread.Stop();
| >>>> }
| >>>> }
| >>>>
| >>>>
| >>>> That is pretty close to what I have. So, I have a couple issues that
| >>>> I'm dealing with. If I have run StartTest() once and call it again
| >>>> later (I handle when it can be called, ListenForInput raises an event
| >>>> when it's done) the _listenerThread's ThreadState is 'Background' so
a
| >>>> subsequent call to Start() throws an exception.
| >>>>
| >>>> I figured I was having this behavior because the thread is a member
of
| >>>> the class rather than local to a method, but I need to have it as a
| >>>> member so that I can cancel it from the UI if a user wishes.
| >>>>
| >>>> I added some code to the end of ListenForInput() that would call
Stop()
| >>>> on the thread, but that seems dangerous to kill the thread you are
| >>>> running on? In fact, is it safe for a process to modify ANYTHING
about
| >>>> a thread it's running on? Like priority or ThreadState?
| >>>>
| >>>> Basically I'm just not sure how to design what I need. The above
class
| >>>> is an accurate model of what I'm after. Most of the threading
examples
| >>>> I have seen online or too simple and don't cover stuff like this.
| >>>>
| >>>> Thanks for reading, I hope someone has some pointers for me.
| >>>> -Steve
| >>>>
| >>>
| >>>
| >>
| >>
| >
| >
|
|

 

[_DD]

Let the third party fix their code, this is all you can do. Calling
Thread.Abort on a thread other than the currently executing thread is BAD,
you don't know what the the thread is actually doing, it's even possible
that he is blocked in unmanaged code, in which case a Thread.Abort won't
help you anyway.

Here's something I was wondering about: If a file is opened in a
thread, and that fileopen is enclosed in a using {} or try/finally
block, does it get auto-closed if the thread is aborted?

I know that a hard return out of the block will still run the
finalizer, but it doesn't seem likely that abort would abide by the
same rules.

 

[Willy Denoyette [MVP]]

| On Tue, 2 May 2006 18:55:37 +0200, "Willy Denoyette [MVP]"
|
| >Let the third party fix their code, this is all you can do. Calling
| >Thread.Abort on a thread other than the currently executing thread is
BAD,
| >you don't know what the the thread is actually doing, it's even possible
| >that he is blocked in unmanaged code, in which case a Thread.Abort won't
| >help you anyway.
|
| Here's something I was wondering about: If a file is opened in a
| thread, and that fileopen is enclosed in a using {} or try/finally
| block, does it get auto-closed if the thread is aborted?
|

Yep, on V2 of the framework, it's guaranteed that'finally' will run
irrespective the kind of exception, of course if your thread blocks
indefinitely in unmanaged code, it won't get aborted so finally will never
run and your file will stay open until the process dies.
If the thread is aborted as a result of an ApplicationDomain unload, things
are a bit more complicated.

| I know that a hard return out of the block will still run the
| finalizer, but it doesn't seem likely that abort would abide by the
| same rules.

You mean 'finally' and NOT finalizer I suppose.

Willy.