RC>   Also is there a list available of which 
 RC> libraries/library functions 
 RC> are multi-thread friendly?  The docs that I've got 
 RC> (the ones that come with Cset++ 2.1) don't seem to

 PF> *ALL* of the functions are multi-thread friendly,  when 
 PF> you compile/link with /Gm.

   OK, I'll keep that in mind.  I have always used /Gm+, but I thought that
some of the libraries weren't multi-threaded.

 PF> This does not prevent you from doing silly things 
 PF> though.  For example,calling getc() for the same stream 
 PF> in different threads will work, but which thread each 
 PF> piece of data goes to is anyone's guess.

   No, I have never done that.  Why would anyone want to share a keyboard
between threads?  IMHO The only way to design an OS/2 application for
interactive performance is to dedicate a single thread to reading from the
keyboard and possibly parsing the input as well.
   Anyway doing that shouldn't cause an exception, which is what I was getting.

 PF> Calling getc() with different streams should work fine. 
 PF>  If you find that your program behaves better when you 
 PF> replace one of the getc's with DosRead(),  you have 
 PF> probably prevented the error by changing the timing of 
 PF> your program (a DosRead() of one byte is a LOT slower 
 PF> than getc()).

   OK.  Well currently I'm using the Kbd*() calls which work well....


  Thanks for all the info, cya.


--- Maximus/2 2.01wb