RL> The only example of doskillthread I've seen is a multi-threaded com app 
 RL> that uses a blocking read from the com port to put 
 RL> bytes into a buffer the user can manipulate.  The only 
 RL> way to get it to go away when you exit is 
 RL> doskillthread. What would you suggest?

If you are exit()'ing your program,  you probably don't need to worry about
shutting that thread down (all threads die when thread 1 dies).

If you need to stop that thread for just a time (you are going to pass the
comm handle to a child program perhaps),  then you need to shut it down.

In this particular case,  I would (from another thread obviously) call the
"set dcbinfo" ioctl to change the read-mode of com.sys to
no-wait,or lower the timeout period,  so that the blocked DosRead()
returns. The read thread would then notice (via some flag/semaphore) that
it is time to shutdown (or pause),  and would do so.

If the thread is being closed down because you are going to stop using the
port forever (ie you are closing it,  to switch to a different port
perhaps),  just call DosClose() from another thread,  and the blocked
DosRead() will return with an error.

>     DosSuspendThread()

 RL> Never used this one.  I take it you should ask a 
 RL> thread to suspend itself?

Most of the time I have seen DosSuspendThread() used (by people who
obviously didn't know what they were doing),  was to manage/serialize
access to a resource;   this is what mutex semaphores are for.


--- Maximus/2 2.02p1