From owner-freebsd-current Wed Apr 14 22:43:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (news.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 07631151F0 for ; Wed, 14 Apr 1999 22:43:49 -0700 (PDT) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40349>; Thu, 15 Apr 1999 15:27:57 +1000 Date: Thu, 15 Apr 1999 15:41:15 +1000 From: Peter Jeremy Subject: Re: swap-related problems To: mi@kot.ne.mediaone.net Cc: current@FreeBSD.ORG Message-Id: <99Apr15.152757est.40349@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mikhail Teterin wrote: >That's my point! I advocate the use of some _other_ signal. Something >catchable. As soon as you allow a catchable signal, you create a potential deadlock situation. See my previous mail. >In case of "resource shortage" the malloc should be unsuccessful >and return NULL. This requires a change to the kernel to disable swap over-commit. malloc is behaving correctly: it calls brk/sbrk to request additional memory. The kernel verifies that the process hasn't exceeded its resource limits and the brk returns success. > Instead, right now you may still get a non-NULL >pointer, but get a SIGKILL when you try to use the rightfully >allocated memory. Actually the biggest process gets SIGKILL. This probably isn't the process that requested the memory. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message