From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 2 21:19:32 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 06B7D16A41F for ; Wed, 2 Nov 2005 21:19:32 +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 8C94643D45 for ; Wed, 2 Nov 2005 21:19: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 jA2LHNVf039347; Wed, 2 Nov 2005 14:17:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 02 Nov 2005 14:17:38 -0700 (MST) Message-Id: <20051102.141738.43008707.imp@bsdimp.com> To: dinesh@alphaque.com From: "M. Warner Losh" In-Reply-To: <43692719.90805@alphaque.com> References: <43690424.1040904@alphaque.com> <20051102.121248.74711520.imp@bsdimp.com> <43692719.90805@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 14:17:23 -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 21:19:32 -0000 In message: <43692719.90805@alphaque.com> Dinesh Nair writes: : : : On 11/03/05 03:12 Warner Losh said the following: : > 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. : : looks like i've got a lot of work to do, poring thru all the ioctls for the : device and trying to use another method to wait instead of tsleep(). If you have to run on 4.x, that may be the case. The other way around this is to create a helper program that gets the ioctl request over a pipe or socket, does the call to the kernel and then returns the results. Not idea, I'll grant, but it is an alternative worth thinking about if the number of ioctls is large and the impact of conversion to read/write channels is big. : > works. If you use libc_r on 5, you'll see exactly this behavior. If : > you use libpthread or libthr, you won't. : : i use gcc -pthread, so it's libc_r on 4.x. what does 'gcc -pthread' link to : on 5.x ? libpthread by default, others if you use libmap.conf Warner