DM> Perhaps adding RTTI support to ensure we ARE 
 DM> dealing with a ThreadBase pointer here... :-)
 JC> It can't be done: you can't use RTTI on a pointer to void.  RTTI has the
 JC> same problem you do at that point: it doesn't know enough about the
 JC> pointer to find out anything.
I thought that RTTI _could_ do this for pointers to void.  Perhaps not, 
though...  It's been a while since I've had access to semi-decent manuals to 
RTTI support.  Right now, I only have GCC that supports it, and at that very 
loosely.  And the documentation for GCC's C++ support is, well, for all 
practical purposes, not there.  Watcom 10.6 doesn't have anything on it that 
I can find.  :-/  Borland/2 1.5?  Let's not even go there.  :-)
 JC> I'm not saving the thread ID, because it's pretty close to useless.
 JC> I'm not even sure why they have thread IDs at all.
 DM> I dunno about Win32, but I know that in OS/2 you can raise other
 DM> thread's priorities, query their state (blocked, 
 DM> running, etc.), block
 DM> them and, , kill them.  (Mind you killing threads has the
 DM> expected side effect of basically destabilizing 
 DM> the entire process and
 DM> the entire process should then shut down immediately, preferably with
 DM> a bit of grace.)  All of this requires the thread ID.
 JC> Under Win32, most, if not all, of this involves the thread handle
 JC> instead of the ID.
Ah.  I'm not sure why Win32 added that... I doubt OS/2 1.3 had it (since 
removing support would break programs, something IBM has committed to not 
doing).  And thus Win32 must support doing this stuff with the original 
16-bit OS/2 calls (killing threads was added in OS/2 3, so that's not an item 
to worry about) using only the thread ID.
 DM> I'm pretty sure there is a fair bit of other stuff.  (For example, in
 DM> my semaphore objects, I need my thread ID in order to figure out if I
 DM> am the thread who owns the semaphore or if it is 
 DM> someone else... I can
 DM> then also figure out who it is so I can kill it )
 JC> Umm...I'm a bit lost as to what you're trying to get at here, though it
I don't recall if the CriticalSection's in Win32 will actually tell you who 
owns a semaphore (in case you want to see if it is blocked, say, so that you 
may have to clear a semaphore to prevent deadlock), but OS/2 does.  This way 
I can ask, "Do I already own the semaphore?"  This is useful for, say, 
private member functions (desperately attempting to stay on topic ) are 
being called according to the "specification."  i.e., function foo::a() can 
only be called when the calling thread has semaphore foo::sem.  I can 
actually be sure of this via assert!
Mind you, I haven't done a lot of threaded applications under OS/2 or Win32, 
so I don't really have much experience to speak too much on this.  :-)
 JC> does give the glimmer of an idea of a use for the thread ID: it allows
 JC> you to identify the thread that owns something _without_ giving a thread
 JC> that receives it any other capabilities such as changing your priority,
 JC> killing you, etc.
Except that you can do all this with the ID under OS/2.  :-)
--- Maximus/2 3.01
---------------