From owner-freebsd-current@FreeBSD.ORG Wed Apr 2 09:21:30 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 290B837B404; Wed, 2 Apr 2003 09:21:30 -0800 (PST) Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C777643FA3; Wed, 2 Apr 2003 09:21:28 -0800 (PST) (envelope-from nate@yogotech.com) Received: from emerger.yogotech.com (emerger.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3p2/8.9.3) with ESMTP id KAA17412; Wed, 2 Apr 2003 10:21:26 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by emerger.yogotech.com (8.12.8/8.12.8) id h32HLMgG032087; Wed, 2 Apr 2003 10:21:22 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16011.7185.945210.92101@emerger.yogotech.com> Date: Wed, 2 Apr 2003 10:21:21 -0700 To: Terry Lambert In-Reply-To: <3E8B03E6.36871704@mindspring.com> References: <3E8B03E6.36871704@mindspring.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid cc: Robert Watson 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 Reply-To: Nate Williams List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 17:21:30 -0000 > > You should notice marked interactivity and UI latency improvements with > > threaded GUI apps over libc_r because GUI threads will generally no longer > > be blocked when disk I/O and blocking I/O occurs. For example, > > applications like Open Office, Netscape, et al, really get a lot better > > with 1:1. Likewise, non-interactive applications that are disk > > I/O-intensive, such as mysql, will also perform substantially better > > because a thread that hits blocking using an interface that doesn't > > support non-blocking I/O (such as the file system) won't clog up the > > application. > > Is the disk I/O really that big of an issue? In my experience, yes. Disk I/O is blocking, since you can't reliably use non-blocking descriptors for disk I/O, since you don't know if it will block, and for how long. Again, in my experience, it was much easier to setup non-blocking networking descriptors, since unlike disk I/O, you needed to deal with things not get written at the application. With disk I/O it was much harder to determine what if anything got written if you did non-blocking writes, and if you needed things written both effeciently and reliably to disk, you *have* to know how much was written successfully, and byte-at-a-time I/O is simply un-acceptably slow. I'm sure others have run into this problem as well. > It seems to me that maybe the correct fix for this is to use > AIO instead of non-blocking I/O, then? AIO is non-portable. Nate