From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 2 19:13:31 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1BE816A41F for ; Wed, 2 Nov 2005 19:13:31 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BCBC43D45 for ; Wed, 2 Nov 2005 19:13:31 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA2JCnMD038139; Wed, 2 Nov 2005 12:12:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 02 Nov 2005 12:12:48 -0700 (MST) Message-Id: <20051102.121248.74711520.imp@bsdimp.com> To: dinesh@alphaque.com From: Warner Losh In-Reply-To: <43690424.1040904@alphaque.com> References: <4361044B.50807@alphaque.com> <20051027.205250.55834228.imp@bsdimp.com> <43690424.1040904@alphaque.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 02 Nov 2005 12:12:49 -0700 (MST) Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 19:13:31 -0000 From: Dinesh Nair Subject: Re: locking in a device driver Date: Thu, 03 Nov 2005 02:23:32 +0800 > > > On 10/28/05 10:52 M. Warner Losh said the following: > > libc_r will block all other threads in the application while an ioctl > > executes. libpthread and libthr won't. I've had several bugs at work > > so if the userland thread does an ioctl, and the the driver goes to > tsleep() when the ioctl is received, all other threads are also blocked > from executing, i.e wont be context switched to run ? Yes. if you tsleep with signals enabled, the periodic timer will go off, and you'll return early. This typically isn't what you want either. > is this behaviour only 4.x specific or is it also there in 5.x ? This behavior is libc_r specific. Any userland threadding library will have these issues. It is fundamental to how userland threadding works. If you use libc_r on 5, you'll see exactly this behavior. If you use libpthread or libthr, you won't. Warner