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/ _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
