Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!cmcl2!edler From: edler@cmcl2.NYU.EDU (Jan Edler) Newsgroups: comp.unix.wizards Subject: Re: signals like interrupts? Message-ID: <17925@cmcl2.NYU.EDU> Date: Mon, 20-Jul-87 16:02:20 EDT Article-I.D.: cmcl2.17925 Posted: Mon Jul 20 16:02:20 1987 Date-Received: Wed, 22-Jul-87 00:38:30 EDT References: <17691@cmcl2.NYU.EDU> <3254@ncoast.UUCP> Reply-To: edler@cmcl2.UUCP (Jan Edler) Organization: New York University, Ultracomputer project Lines: 37 In article <3254@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >Cases where trapping hardware signals is desirable: > >(1) my malloc() debugger package (soon in comp.sources.misc) dumps the malloc >tables when an invalid memory access (SIGBUS, SIGSEGV) occurs; this allows >the programmer to determine if it was a bogus pointer reference. Clearly there is a need to trap hardware-generated signals; what I am denying is that there is any need to block or ignore them. >(2) I often send SIGBUS to a process which traps SIGQUIT and then goes into >an infinite loop. I want the core dump, else I would use SIGKILL. Remember: >_no_ program is ever totally bug-free! Perhaps what is needed is a non-catchable terminate-with-coredump signal. Remember: the program might be catching SIGBUS too. Also, the existence of a user-sendable SIGBUS makes it hard to do implementation-specific extensions such as passing extra arguments to the handler in a reliable way. >As for queueing: what's wrong with the System V technique? Send a message, >then a SIGUSR1; it doesn't matter how many SIGUSR1's are lost as long as you >get one of them, and the IPC msg mechanism does the queueing. You can send >data asynchronously this way as well. The SIGUSR1 handler can deal with the >messages. It all depends on what your application is. For most traditional uses of signals, it doesn't matter whether they are queued or not. For message passing over a separate ipc channel, it is also unnecessary to queue signals. But if you need to be able to count them, or if the signals are accompanied by extra information (e.g. asynchronous i/o completion info), then requiring use of a separate ipc channel is at least awkward. Jan Edler NYU Ultracomputer project edler@nyu.edu ...!cmcl2!edler (212) 998-3353