From owner-freebsd-threads@FreeBSD.ORG Sun Oct 9 02:45:50 2005 Return-Path: X-Original-To: threads@freebsd.org Delivered-To: freebsd-threads@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C80AB16A41F; Sun, 9 Oct 2005 02:45:50 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B7CF43D46; Sun, 9 Oct 2005 02:45:50 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id j992jnov001555; Sat, 8 Oct 2005 22:45:49 -0400 (EDT) Date: Sat, 8 Oct 2005 22:45:49 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Robert Watson In-Reply-To: <20051008165620.T17032@fledge.watson.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: threads@freebsd.org Subject: Re: SIGINFO interrupts connect() with libpthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2005 02:45:50 -0000 On Sat, 8 Oct 2005, Robert Watson wrote: > > On Sat, 8 Oct 2005, Daniel Eischen wrote: > > > It only works with libc_r because libc_r wraps all these calls > > (including connect()) with poll(). Obviously we're not going to do that > > with libpthread. You're only seeing it with SIGINFO because we use > > SIGINFO as a debugging signal for libpthread (to dump thread state). > > libpthread doesn't install any other signal handlers unless the > > application does. We could use a different signal or not use SIGINFO at > > all. > > Ah, so this is why my /tmp is full of garbage :-): > > As you might guess, I like to hit ^T to find out what an application is > doing. Regardless of whether the application has its own SIGINFO handler > or not. libpthread should not implement SIGINFO unless some or another > special circumstances apply -- environmental variable, or compile option, > or such. Well, libc_r has been that way for years and it just carried over into libpthread. We could add another signal, but I'm confused on how signals should be added. We allow up to 128 signals, but only have 31 (up to SIGUSR2) defined and usable. When SIGTHR was added, NSIG wasn't bumped so it isn't found in valid signals by kill(1), and anything added after it would not be either without bumping NSIG. The comments for NSIG also say "number of old signals" and implies that new signals can be added without bumping NSIG. So either the comment is wrong, or kill(1) is wrong. And lib/libc/gen/siglist.c also bases everything on NSIG. -- DE