Date: Fri, 19 Sep 2003 02:24:06 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: deischen@freebsd.org Cc: Dan Langille <dan@langille.org> Subject: Re: [PATCH] : libc_r/uthread/uthread_write.c Message-ID: <3F6ACB36.1446DAAB@mindspring.com> References: <Pine.GSO.4.10.10309180745410.24282-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F6ACB36.1446DAAB>