From owner-freebsd-hackers Sun Aug 12 5:53:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9C56F37B403; Sun, 12 Aug 2001 05:53:12 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA16653; Sun, 12 Aug 2001 08:52:21 -0400 (EDT) Date: Sun, 12 Aug 2001 08:52:20 -0400 (EDT) From: Daniel Eischen To: Michael Robinson Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: _sigprocmask in malloc.c causes full file table? In-Reply-To: <20010812152655.A1569@elephant.netrinsics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 12 Aug 2001, Michael Robinson wrote: > Julian Elischer wrote: > >Malloc is not re-entrant...i.e. > >you cannot use in in a signal handler.. > > Thank you for that very helpful bit of information, but I already knew that. > > What I do not know is how it is possible for a null _sigprocmask call > (a SIG_BLOCK call with no mask bits set) in libc/stdlib/malloc.c to cause a > kernel error, "file: table is full", in libc_r/uthread/uthread_init.c. This is the first time that I saw libc_r was involved. Actually, POSIX (1003.1, 1996) says this about sigprocmask: "The use of the sigprocmask() function is unspecified in a multithreaded process." FreeBSD behaviour of sigprocmask() is the same as Solaris. sigprocmask() changes the mask of the calling thread, not the process. In other words, it is identical to pthread_sigmask(). If it is being used to block signals for threads other than the calling thread, it won't work. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message