From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 2 21:16:00 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 3FC1A16A41F for ; Wed, 2 Nov 2005 21:16:00 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AC4E43D46 for ; Wed, 2 Nov 2005 21:15:59 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jA2LFmx0073555; Wed, 2 Nov 2005 14:15:48 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43692C86.4040509@samsco.org> Date: Wed, 02 Nov 2005 14:15:50 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dinesh Nair References: <4361044B.50807@alphaque.com> <20051027.205250.55834228.imp@bsdimp.com> <43690424.1040904@alphaque.com> <20051102.121248.74711520.imp@bsdimp.com> <43692719.90805@alphaque.com> In-Reply-To: <43692719.90805@alphaque.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org 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:16:00 -0000 Dinesh Nair wrote: > > > 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(). Note that a thread can block on select/poll in 4.x and still allow other threads to run. I used this to solve a very similar problem to your in a 4.x app of mine. I have the app thread wait on select() on the device node for the driver. When the driver gets to a state when an ioctl won't block (like data being available to read), then it does the appropriate magic in it's d_poll method. select in userland sees this, allows the thread to resume running, and the thread then calls ioctl. Of course you have to be careful that you don't have multiple threads competing for the same data or that the data won't somehow disappear before the ioctl call runs. But it does work. Look at the aac(4) driver for my example of this. The other option is to use rfork, aka 'linuxthreads' to similate threads via linked processes that share their address space. Each 'thread' is actually a process, and if one 'thread' blocks the rest are still allowed to run. It's more heavy-weight than real threads, but it does also work. > >> 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 ? > lpthread, I believe. Scott