allbery@ncoast.ORG (Brandon S. Allbery) (05/08/89)
This should by rights be a followup, but the References: line is too long
for either our inews or our rn to cope with.
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.
++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@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuserjas@ernie.Berkeley.EDU (Jim Shankland) (05/09/89)
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 dedicate a thread to signal handling by having it call a modified pause(). A signal causes the pause()'d thread to run. It can abort its sister lwp's and/or start new ones, if it desires. Obviously, you also need inter-thread synchronization primitives. This approach has the advantage of making the parallelism implicit in signal handlers explicit, allowing problems like heap corruption due to signal in mid-malloc to be confronted head-on. Jim Shankland jas@ernie.berkeley.edu "Blame it on the lies that killed us, blame it on the truth that ran us down"
allbery@ncoast.ORG (Brandon S. Allbery) (05/14/89)
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@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser