From owner-freebsd-current Thu Apr 15 11:26:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from misha.cisco.com (misha.cisco.com [171.69.206.50]) by hub.freebsd.org (Postfix) with ESMTP id E230715275 for ; Thu, 15 Apr 1999 11:26:04 -0700 (PDT) (envelope-from mi@misha.cisco.com) Received: (from mi@localhost) by misha.cisco.com (8.9.2/8.9.1) id OAA98506; Thu, 15 Apr 1999 14:22:57 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <199904151822.OAA98506@misha.cisco.com> Subject: Re: swap-related problems In-Reply-To: <199904151743.KAA02998@dingo.cdrom.com> from Mike Smith at "Apr 15, 1999 10:43:55 am" To: mike@smith.net.au (Mike Smith) Date: Thu, 15 Apr 1999 14:22:56 -0400 (EDT) Cc: current@freebsd.org Reply-To: mi@aldan.algebra.com X-Mailer: ELM [version 2.4ME+ PL52 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith once wrote: > > >A signal handler is not guaranteed to work. It must be written > > >such that it does not require a new page of memory. Some possible > > >problems here are the stack growing, writing on a new page in the > > >data segment, etc. > > > > man sigaltstack > That doesn't help; there is no guarantee that your stack or your > alternate stack have been mapped. Can I ensure the room availability for the signal handler by explicitly calling it once, _before_ doing the dangerous operation of touching every page of the freshly allocated memory? The thing itself (in the case of earlier described `safe malloc') will only change a value of a static variable and return, indicating to the malloc it should: . stop the touching . give the memory back to system . return NULL to the caller. This assumes, of course, that it is the process doing the malloc that is sent the signal, AND, that the signal is catchable. The kernel can try to remember the processes the signal went to, and send it a SIGKILL if it happens again withing a certain time -- to avoid the deadlock. Pretty horrible? Feasible? -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message