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