From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 19 04:27:31 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 B4D3616A4B3 for ; Fri, 19 Sep 2003 04:27:31 -0700 (PDT) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1724A43F75 for ; Fri, 19 Sep 2003 04:27:31 -0700 (PDT) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 6B6E63D28; Fri, 19 Sep 2003 07:27:21 -0400 (EDT) From: "Dan Langille" To: Terry Lambert Date: Fri, 19 Sep 2003 07:27:24 -0400 MIME-Version: 1.0 Message-ID: <3F6AAFDC.10680.145CA650@localhost> Priority: normal In-reply-to: <3F6ACB36.1446DAAB@mindspring.com> X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body cc: hackers@freebsd.org 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 11:27:31 -0000 On 19 Sep 2003 at 2:24, Terry Lambert wrote: > 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. My issue does not concern stalls. It concerns lost data bacause EOT of not correctly signalled. See http://www.freebsd.org/cgi/query- pr.cgi?pr=56274. But if I've missed the point, could someone please provide a Terry- English translation? I tried http://babelfish.altavista.com/ but had no succeess. -- Dan Langille : http://www.langille.org/