Xref: utzoo comp.sys.next:7710 comp.os.mach:528 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!mtxinu!sybase!pluto!brenegan From: brenegan@pluto.sybase.com (david brenegan) Newsgroups: comp.sys.next,comp.os.mach Subject: Re: Threads and signals Message-ID: <10967@sybase.sybase.com> Date: 19 Sep 90 16:25:15 GMT References: <1990Sep16.202349.20124@ux1.cso.uiuc.edu> Sender: news@Sybase.COM Organization: Sybase, Inc. Lines: 57 >Robert Olson writes: > >>[..good stuff deleted..] > Bill schilit writes: >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). [..other good stuff deleted...] > This is a very fundamental problem with mach and unix as bill points out. This really is a common problem. The way I am dealing with this problem is I have a thread that does nothing but catch exceptions, in my case I use EXC_SOFTWARE. This exception thread listens to all the threads exception ports ( I actually allocate and set the exception port I listen to using the port_allocate() and task_set_special_port() routines.) This exception thread simply waits, blocked in msg_receive() waiting for an exception to happen. Once we receive on we pass the message to a special 'exception server', on NeXT this is called exc_server(). exc_server() returns us a message which we must then do a msg_send() with, otherwise the the thread permanently blocks and things don't work, this is apparently a mach feature. This is *all* the exception thread does, looping around blocking again in msg_receive(). The routine catch_exception_raise(), does the real work. This guy needs to first stop the thread that will run the signal handler, via thread_suspend(). Interrupt the current system call in progress (if there was one in progress), via thread_abort(), get the processor registers, via thread_get_state(). And then set up the pc, etc. to call the correct signal handler according to information you can pass in to this routine (catch_exception_raise()). Then call thread_resume(). If things are set up correctly, you will execute the signal handler in the thread that it should be executing in, and return to what you were doing before the interrupted system call. In order for this all to work, you also need to have a generic signal handler, that just calls exception_raise(). In this routine you would say the exception is EXC_SOFTWARE, and probably set the type of signal in the subcode variable passed to this routine. (see exception_raise(), as bill says...). There are some bugs/features on NeXT that may prevent you from having this work successfully for you. I have working examples of what I just discussed but I'm running in to some problems that NeXT is trying to get working for me. I hope this little discussion helps you in your endevours. Cheers, _David Brenegan Sybase Inc. brenegan@sybase.com