From owner-freebsd-current@FreeBSD.ORG Wed Apr 2 16:23:43 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09AE137B410 for ; Wed, 2 Apr 2003 16:23:43 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EC8143F85 for ; Wed, 2 Apr 2003 16:23:42 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0436.cvx22-bradley.dialup.earthlink.net ([209.179.199.181] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 190sW1-0004Pt-00; Wed, 02 Apr 2003 16:23:38 -0800 Message-ID: <3E8B7EAD.EAAD8533@mindspring.com> Date: Wed, 02 Apr 2003 16:22:05 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Roberson References: <20030402183406.O64602-100000@mail.chesapeake.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a429b0264bfe50ac3033146ede650efb25a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: csujun@21cn.com cc: current@freebsd.org Subject: Re: libthr and 1:1 threading. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 00:23:43 -0000 Jeff Roberson wrote: > On Wed, 2 Apr 2003, Terry Lambert wrote: > > Peter Wemm wrote: > > > No. It gives the ability for a thread to block on a syscall without > > > stalling the entire system. Just try using mysqld on a system using libc_r > > > and heavy disk IO. You can't select() on a read() from disk. Thats the > > > ultimate reason to do it. The SMP parallelism is a bonus. > > > > Bug in FreeBSD's NBIO implementation. A read() that would result > > in page-in needs to queue the request, but return EAGAIN to user > > space to indicate the request cannot be satisfied. Making select() > > come true for disk I/O after the fault is satisfied is a seperate > > issue. Probably need to pass the fd all the way down. > > Please quote the standard that defines this behavior. This is entirely > counter to everything that I have ever read on the subject. There's no "standard" that specifies this behaviour, but there's code that defines it. I believe this is the way BSD 4.2 and 4.3 worked. You could maybe as Kirk about it, if you don't want to believe me on it. The thing that broke it was the switch to the vnode abstraction seperation from the fd, going to a vnode-based pager, and the switch to a unified VM and buffer cache. At that point, the non-blocking I/O flags weren't available to the pager to enable it to make a decision on whether or not to block the process pending completion of the paging operation. SVR4 and Solaris both support doing this; I used it to great effect in SVR4.0.2 in 1994 for NetWare for UNIX, at Novell. It's pretty clear from just thinking about the idea that it makes sense, if you are using non-blocking I/O, to start the operation and return early. It's the same effect that's exploited by having a seperate context to use for each blocking operation. -- Terry