Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cwjcc!hal!ncoast!allbery From: allbery@ncoast.ORG (Brandon S. Allbery) Newsgroups: comp.unix.wizards Subject: Re: Avoiding longjmp Message-ID: <13640@ncoast.ORG> Date: 13 May 89 19:40:19 GMT References: <13624@ncoast.ORG> <29105@ucbvax.BERKELEY.EDU> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.unix.wizards Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 22 As quoted from <29105@ucbvax.BERKELEY.EDU> by jas@ernie.Berkeley.EDU (Jim Shankland): +--------------- | In article <13624@ncoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes: | >Might I suggest that the proper method for dealing with asynchronous signals | >of any sort without "longjmp" or its equivalent has been known for some time | >now. It's called an event loop. | | At the risk of getting into a "dessert topping/floor wax" argument: | the proper method for dealing with asynchronous signals is light-weight | processes (a.k.a. threads). Forget signal handlers altogether: you +--------------- Good point. Let me modify my assertion to "the proper method of dealing with asynchronous signals *when lightweight processes are not available*". I'm not talking about Mach; I'm talking about the rest of us. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@ NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser