From owner-freebsd-current Wed Mar 1 13: 8:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 8FCBF37BEBF for ; Wed, 1 Mar 2000 13:08:33 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115221>; Thu, 2 Mar 2000 08:09:19 +1100 Content-return: prohibited From: Peter Jeremy Subject: Re: Process cleanup (was Shared memory ...) In-reply-to: <200003012000.e21K04x04001@orthanc.ab.ca>; from lyndon@orthanc.ab.ca on Thu, Mar 02, 2000 at 07:10:39AM +1100 To: Lyndon Nerenberg Cc: current@FreeBSD.ORG Message-Id: <00Mar2.080919est.115221@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <200003011928.LAA75785@vashon.polstra.com> <200003012000.e21K04x04001@orthanc.ab.ca> Date: Thu, 2 Mar 2000 08:09:17 +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-Mar-02 07:10:39 +1100, Lyndon Nerenberg wrote: >I'm too lazy to look right this second ;-) ... do atexit() functions get >run when a process takes (say) a segmentation fault? Nope. If there's no userland signal handler, the process will never return to userland after a signal. If you really wanted to, you could add handlers for all the signals and make them call the atexit() functions before dying, but that would get messy (since the process state is probably indeterminate if it got an unexpected signal). As various people have pointed out, SysV IPC is mostly an abomination. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message