Xref: utzoo comp.sys.next:7655 comp.os.mach:525 Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker!mit-eddie!rutgers!cunixf.cc.columbia.edu!cs.columbia.edu!bill From: bill@cs.columbia.edu (Bill Schilit) Newsgroups: comp.sys.next,comp.os.mach Subject: Re: Threads and signals Message-ID: Date: 17 Sep 90 04:14:13 GMT References: <1990Sep16.202349.20124@ux1.cso.uiuc.edu> Sender: bill@cs.columbia.edu (Bill Schilit) Organization: Columbia University Department of Computer Science Lines: 39 In-Reply-To: olson@sax.cs.uiuc.edu's message of 16 Sep 90 20:23:49 GMT Robert Olson writes: >I'm trying to take an existing application and create a thread to >handle some communication with another application via a port (I'm >actually using the NextStep speaker/listener). The problem is that the >application is using SIGIO to notify itself of keypresses. When I add >another thread for communication, the communication thread is the one >that actually gets the signal, some of the time (when I type quickly at >the application), hanging the application. Is there any way I can keep >the thread from getting the signal? I tried doing a sigblock, but then >the application didn't get the signals either. Robert, The problem you are having with mach threads and unix signals is because threads and signals don't mix (one is unix and the other isn't). Signals are either synchronous -- caused by the program flow -- or asynchronous. Synchronous signals (like illegal memory reference) are handled by the mach exception handler in the unix emulation code and are correctly sent to the offending thread (the one generating the exception condition). See ux_exception.c and catch_exception_raise(). Asynchronous signals on the other hand (like your SIGIO) are delivered willy nilly to the first thread that happens to go past some code in the kernel. Doing things like sigblock are only going to cause problems because these *unix* system calls effect all threads in the task. So I think your options are: (1) You can structure your code so that the SIGIO handler can run in any thread. (2) you can catch the signal in any thread and wakeup or interrupt your IO thread. If you decide to interrupt you may be able to get some code from Xerox PARC that simulates signals directed at a particular thread, however, this is expensive and should be avoided. - Bill -- Bill Schilit Columbia University Computer Science Department bill@cs.columbia.edu