Denis Tonn wrote in a message to Mike Bilow:

MB> Also, can the Rexx program receive a halt signal when its 
MB> own thread of execution is in a separate Rexx-callable DLL 
MB> that I don't control, which is the most likely case for my 
MB> timeout to trigger?

 DT> Hmm.. I suspect that as long as the thread is blocked *in*
 DT> the other  DLL code, that the halt will not be driven. But
 DT> in most cases these  kinds of DLL functions will have a
 DT> timeout that will eventually return to the subcommand
 DT> enviroment (REXX.DLL code). Then the halt would be  driven.
 DT> On the other hand, REXX registers some exception handlers of
 DT> it's own, and these may be what it uses to detect and drive
 DT> a halt  condition. It would take a debugging session to be
 DT> sure. 

This is the key question.  I either knew or figured out all of the other
stuff.  If I could depend upon the other DLL (RXFTP, actually) timing out,
then I would not need this watchdog DLL.  The documentation says that
RexxSetHalt() sets a flag somewhere inside Rexx, and the implication was
that this would not be tested until the other DLL returned from its called
function, so this would not do what I need.  This is why I was looking at
DosKillProcess() instead of RexxSetHalt(); as I said, I don't so much care
about cleaning up properly, since the whole point is to create a last-ditch
fail-safe mechanism.

When I get a chance, what I was going to do was test by passing the main
thread of execution into SysSleep() and seeing whether RexxSetHalt() works
from the watchdog thread.  I know that hitting Ctrl-Break will terminate a
Rexx script even if it is in a DLL function such as SysSleep() or FtpGet(),
so it is entirely possible that RexxSetHalt() will work.

 DT> Most of this stuff is in the OS/2 toolkit in an INF called 
 DT> REXXAPI2.INF. I'll admit it is not well organized, but it is 
 DT> there.  

I have written Rexx-callable DLLs before, but I have never done one that
was multithreaded or one that tried to take such vicious action as killing
its own process while in an effective deadlock state.
 
-- Mike


---