🚀 go-pugleaf

In article <1688.25a364a4@cc.helsinki.fi> kulokari@cc.helsinki.fi writes:
> ...    
>This is simple and beautiful, and works well until you try to exit. Because
>both threads are always waiting for the "next" keyin/mouse event, you must both
>press a key and click the mouse before the threads get the change to notice
>that they are expected to die. Of course, if you just brutally exit the
>program, the threads will be gone too, but in many cases this is not what you
>want.
 
You might try closing the mouse/keyboard handles from another thread, which
*may* have the effect of causing the waits in the key/mouse threads to abort.
That works in a similar situation for device monitors.  At least, it works
with OS/2 1.1; I've had some preliminary indication maybe it doesn't always
work with 1.2.   
 
An alternative, of course, is to spawn a separate process to contain the 
threads that wait on mouse and keyboard, and to have them communicate back
to the main thread via IPC or shared memory.  Then you can just kill this 
process and restart it when you want to wait again.
 


>...  And there should be a way to
>kill threads, as there is a way to kill processes (sessions). Perhaps
>in a future release...
 
I agree.  The lack of anyway to kill a thread or abort a thread's wait is 
one of the more glaring omissions in the OS/2 API. 
 



Alan Ballard                   | Internet: Alan_Ballard@mtsg.ubc.ca
University Computing Services  |   Bitnet: USERAB1@UBCMTSG
University of British Columbia |    Phone: 604-228-3074
Vancouver B.C. Canada V6R 1W5  |      Fax: 604-228-5116