From owner-freebsd-arch Tue Jun 20 10:40:47 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id E08BF37B5A5 for ; Tue, 20 Jun 2000 10:40:37 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id KAA01055; Tue, 20 Jun 2000 10:40:49 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp05.primenet.com, id smtpdAAAgYa48b; Tue Jun 20 10:40:38 2000 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id KAA20126; Tue, 20 Jun 2000 10:40:22 -0700 (MST) From: Terry Lambert Message-Id: <200006201740.KAA20126@usr01.primenet.com> Subject: Re: kernel thread support To: jasone@canonware.com (Jason Evans) Date: Tue, 20 Jun 2000 17:40:22 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <20000616144259.Q47268@blitz.canonware.com> from "Jason Evans" at Jun 16, 2000 02:42:59 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't know if this has been reported yet. The send-pr system hates my machine because it uses unpublished DNS information. This is posted to arch, since an architectural decision on what the correct behaviour of signal(3) should be: no matter which way the decision goes, it appears to me that libc and libc_r should behave the same way. --- FYI, after I helped someone track down a hanging problem in OpenLDAP, it was pointed out that the libc_r "signal" symbol is omitted in the list of weak exports, and so even if you link with libc_r, you get the libc version. The libc and libc_r versions differ, in that the libc_r version does not restart system calls, while the libc version does. This is apparently a BSD legacy issue with using the non-POSIX signals interface, and getting variant behaviour. It is probably more correct to explicitly use the POSIX interface, and call the sigaction() call directly, with sa_flags = 0, but OpenLDAP and other code is unliekly to change in this regard. Using siginterrupt() didn't help; it is apparently not threads-aware, or there is an order of operations bug in its libc_r implementation. For OpenLDAP, the libc_r version is correct; it permits users to send SIGTERM to the LDAP server to shut it down. This can be fixed by adding "signal.o" to the "HIDDEN_SYSCALLS" variable in the libc_r Makefile. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message