From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 19 02:25:14 2003 Return-Path: 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 B5BFC16A4B3; Fri, 19 Sep 2003 02:25:14 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00ABC43F3F; Fri, 19 Sep 2003 02:25:14 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfmp3.dialup.mindspring.com ([165.247.219.35] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A0HVm-0004u4-00; Fri, 19 Sep 2003 02:25:12 -0700 Message-ID: <3F6ACB36.1446DAAB@mindspring.com> Date: Fri, 19 Sep 2003 02:24:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: deischen@freebsd.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a41a8f75e87e82ebb338d38bbe296fd0712601a10902912494350badd9bab72f9c350badd9bab72f9c cc: hackers@freebsd.org cc: Dan Langille Subject: Re: [PATCH] : libc_r/uthread/uthread_write.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2003 09:25:14 -0000 Daniel Eischen wrote: > > > If you are using libkse or > > > libthr, you will get a partial byte count and not zero because > > > the tape driver returns the (partial) bytes written. So exiting > > > the loop in libc_r and returning 0 would only seem to correct > > > the "problem" for libc_r. > > If there is a difference, it could be because libc_r is using non-blocking > IO behind the scenes, and sa(4) may be returning partial byte count > in the non-blocking case and 0 (or -1 and ENOSPC) in the blocking case > (which is what you'd get using libkse/libthr). I would think that for non-block multiple and/or non-block-aligned writes, there's no way to avoid the fault-in penalty for the need to do read-before-write, so there will always be some unavoidable stalls. -- Terry