From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 3 13:26:15 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 BDE6516A420 for ; Thu, 3 Nov 2005 13:26:15 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8606343D8D for ; Thu, 3 Nov 2005 13:25:50 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm513-1.comsys.ntu-kpi.kiev.ua (pm513-1.comsys.ntu-kpi.kiev.ua [10.18.52.101]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.12.10/8.12.10) with ESMTP id jA3DYecp082273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Nov 2005 15:34:43 +0200 (EET) Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 7F88A5C029; Thu, 3 Nov 2005 15:25:00 +0200 (EET) Date: Thu, 3 Nov 2005 15:25:00 +0200 From: Andrey Simonenko To: Dinesh Nair Message-ID: <20051103132500.GA73085@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20051027.205250.55834228.imp@bsdimp.com> <43690424.1040904@alphaque.com> <43690EED.10703@elischer.org> <20051102.132709.101593999.imp@bsdimp.com> <436927AE.4030809@alphaque.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <436927AE.4030809@alphaque.com> User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/1158/Wed Nov 2 15:29:56 2005 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean 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: Thu, 03 Nov 2005 13:26:15 -0000 On Thu, Nov 03, 2005 at 04:55:10AM +0800, Dinesh Nair wrote: > > On 11/03/05 04:27 M. Warner Losh said the following: > >that this is the case: sleep in an ioctl, and the entire process hangs > >until the ioctl returns. > > which is probably what's happening in my case. i've got 4 threads spun off, > and one thread reads what the other writes and vice versa. after writing, a > thread goes off into an ioctl or a read where a tsleep() is executed. this > would block the reader thread as well if libc_r were to be used, as is what > i am using. Having read all messages (really interesting) in this thread, I decided to add some words. Multi threaded application which uses user level thread library always will have problems if used user level thread library is not aware about some function which can block in the kernel. According to my understanding... Blocking operations on file descriptors internally in user level thread library are converted to non-blocking and library periodically checks for events on such descriptors (at least before switching to another userland thread, somewhere in signal handler (user level scheduler), which is used in the same style as hardware clock). And application does not need to do anything to convert all blocking syscalls to non-blocking versions. Since implementation of ioctl() (own device's part), is unknown to the library (really it is unknown also for the kernel) it is impossible to say from the userland if this system call is blocking or not. As I remember, SysV semaphores had the same problem in <4.x (but it seems that it is possible to fix this problem, again nonblocking variant with periodic checks). The same problem with custom syscalls (they like custom ioctls).