[PATCH] : libc_r/uthread/uthread_write.c

[Dan Langille]

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/