Some senseless babbling from Vitus Jensen to Mike Ruskai
on 08-24-99  01:25 about Terminating threads clean...

 VJ> Hello Mike,

 VJ> 19.08.99 20:06, MIKE RUSKAI wrote a message to VITUS JENSEN:

[snip]
 
 MR> I don't know what other resources that would need to be recovered
 MR> from a thread.  As far as I can figure, a thread should release
 MR> any resources it's using by itself.

 VJ> The only resource DosWaitThread() could release is the exit code of
 VJ> the thread it waited for.  Obviously this information has to be stored
 VJ> somewhere outside of the died thread.  Writing another test program ...
 VJ> No, there is no difference between starting 200000 threads with and
 VJ> without DosWaitThread.  Either OS/2 uses a fixed size table or the
 VJ> amount of storage is to small to get noticed.

I just looked over the CP reference, and it was never stated (even 
implicitly) that DosWaitThread() *should* be called to recover resources.  
It was presented only as an option.  And it is also explicitly stated that 
the thread information block is maintained by the operating system.  That's 
the only memory allocated for each individual thread, apparently, and if 
OS/2 relied on DosWaitThread() to release that storage, the result would be 
a big memory leak.

My best guess is that OS/2 keeps a static array that indicates whether the 
thread ID is occupied, and holds a pointer to the TIB (and an indicator to 
which process ID it belongs).  My speculation beyond that is that when 
threads of a process are terminated, the process ID indicator remains 
intact, as well as the TIB storage.  When new threads are started, they are 
first given ID's that are not associated with any running processes, and 
when they are exhausted, begins recycling thread ID's that were previously 
used in the current process, and overwrites the TIB information.  At 
process end, all TIB structure storage for the process is released, and 
process ID associations removed.  

If my guess is correct (or nearly so), then there's no guarantee that the 
information in the TIB and TIB2 will remain valid after the thread has 
terminated, and before DosWaitThread() is called.  Of course, I don't see 
anything in that structure that's useful after the thread has ended, 
anyway.  If all thread ID's have TIB and TIB2 storage associated with them, 
that'd be only 160K of memory, which isn't very noticeable on the whole.

However, it is enough to notice in your test, probably, so the order of 
thread ID assignment may be either the opposite of what I suggested, or 
have no order a tall.  That is, either thread ID's previously used by the 
process are recycled first, or they are simply assigned in numeric order, 
without regard to which process they were previously associated with.  The 
latter looks perhaps more likely, as clearly thread ID's previously used by 
one process are available to other processes, even while the first process 
is still running.  Otherwise, something as simple as a daemon process that 
processes requests on newly-begun threads would quickly exhaust the 
system's thread resources.

Finally, I may be missing something, but I don't find anywhere for a thread 
to provide a return code, save in a structure pointed to by the thread's 
argument, which must be maintained by the application.

Mike Ruskai
thannymeister@yahoo.com


... Almost everything in life is easier to get into than out of.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
2604/104