From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 3 12:57:43 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 57A2C16A41F for ; Thu, 3 Nov 2005 12:57:43 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1287243D45 for ; Thu, 3 Nov 2005 12:57:43 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms061.mailsrvcs.net ([192.168.1.2]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IPD00FRQQO6VMC1@vms046.mailsrvcs.net> for freebsd-hackers@freebsd.org; Thu, 03 Nov 2005 06:57:42 -0600 (CST) Date: Thu, 03 Nov 2005 06:57:42 -0600 (CST) From: Sergey Babkin To: "M. Warner Losh" , scottl@samsco.org Message-id: <20669850.1131022662391.JavaMail.root@vms061.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailman-Approved-At: Thu, 03 Nov 2005 13:37:01 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Re: locking in a device driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 12:57:43 -0000 >From: "M. Warner Losh" > Scott Long writes: >: 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. > >Yes. If you have the ability to know that an ioctl won't block before >you call it, that would work too. This method is a little trickier, >like you say, but can be made to work. I've also seen ioctls that Maybe it can be fixed in the kernel without too much trouble. Basically, the trick would be to start another kernel thread when the first one blocks. Then the original one can be left executing the ioctl while the new one continues the work. Then of cours ethere should be some notification mechanism that the ioctl has completed. The new thread can start in a signal handler, kind of like what UnixWare does (and I believe Solaris too): they have an M:N model where M user threads are scheduled on N kernel threads. When all the kernel threads of a process get blocked, a signal is sent thread which handler then starts a new kernel thread if there are any runnable user threads. Hm, suppose we have a per-process property "is threaded" that would be set by the threads library. Any blocking calls (tsleep() and such) would check it, and if it's set than immediately post this "all threads are blocked" signal. Then the library can catch it and handle in some useful way, maybe doing an rfork() or just running another user thread and returning to this one later. -SB