Hi MIKE,

30.08.99 00:43, MIKE RUSKAI wrote a message to VITUS JENSEN:

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

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

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

So my memory may refer to some other OS with thread support (NetWare or
WinXy).


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

(refering to OS/2 Debugging Handbook Vol 4)
There is a linked list of Thread Control Blocks (TCB) in the Per Task Data
(PTDA).  There seems to be a difference between /active/ and not so active
TCBs.
A TCB holds a pointer to TIB (which doesn't contain an exit code as you wrote) 
and a ptr to an Thread Swappable Data (TSD).  This TSD holds a field called
/TSDulExitCode/ ("proposed Thread Exit Code").


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

TSDs are allocated in the system arena (above 512MB) so more or less allocated 
TSDs can't be noticed by looking at the available adress space for user
processes.  Unfortunately my machine has enough swap space so it can't be
noticed by looking at the available memory.  Even the /resident/ memory won't
grow as TSDs are swapable.
I think one needs something like Theseus to detect any changes.


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

?  I don't understand: do you think about something more than the value passed 
to return?

C-x C-s
    Vitus

--- Sqed/rexx 440: