Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!think!snorkelwacker!bloom-beacon!eru!luth!sunic!tut!hydra!hylka!kulokari
From: kulokari@cc.helsinki.fi
Newsgroups: comp.os.os2
Subject: Re: Keyboard, mouse and threads (Was: Re: uEMACS)
Message-ID: <1696.25a4da7a@cc.helsinki.fi>
Date: 5 Jan 90 17:33:46 GMT
References: <5345@udccvax1.acs.udel.EDU> <976@tuminfo1.lan.informatik.tu-muenchen.dbp.de> <1654.2590d3f4@cc.helsinki.fi> <1020@tuminfo1.lan.informatik.tu-muenchen.dbp.de> <1688.25a364a4@cc.helsinki.fi> <6155@ubc-cs.UUCP>
Organization: University of Helsinki
Lines: 23

In article <6155@ubc-cs.UUCP>, ballard@cheddar.cc.ubc.ca (Alan Ballard) writes:
> 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.   

I tried. Does not work. 
>  
> 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.

I thought that. Somehow I feel it is overkill for such a simple and basic
task. Separate exe file and all that.


Hannu Kulokari
CC, U of Helsinki

kulokari@cc.helsinki.fi (Internet)
kulokari@finuh (Bitnet)