Date: Thu, 18 Sep 2003 07:50:55 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Dan Langille <dan@langille.org> Cc: hackers@freebsd.org Subject: Re: [PATCH] : libc_r/uthread/uthread_write.c Message-ID: <Pine.GSO.4.10.10309180745410.24282-100000@pcnet5.pcnet.com> In-Reply-To: <3F683824.14446.AB8FEDA@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Sep 2003, Dan Langille wrote: > On 16 Sep 2003 at 20:49, Daniel Eischen wrote: > > > On Tue, 16 Sep 2003, Dan Langille wrote: > > > > > I've had preliminary success with this patch. More testing needs > > > to be done, but in the meantime, I would appreciate reviews and > > > comments. The patched code is available from > > > http://beta.freebsddiary.org/tmp/uthread_write.c and the patch > > > appears below. > > > > > > In short, the logic has been changed to ensure that if __sys_write > > > returns zero, this value is returned by _write. > > > > I think this is not quite correct. Since libc_r is looping > > and some data may have been read, then the partial byte count > > should be returned, not zero. It is possible the partial byte > > count could also be zero in some cases, so it would result > > in zero being returned in those instances. > > I see what you mean. Please have a look at > http://beta.freebsddiary.org/tmp/uthread_write.c2 > The patch appears at the end of this message. Right, this seems correct to me. > > This version will return the partial byte count (which has always > been zero in testing) but exit the loop if the return code is zero. Hmm, I was under the impression that partial byte count was returned, but OK... > > I think the problem lies with the SCSI tape device. It should > > either return 0 or -1 with errno=ENOSPC on a write that detects > > an EOT, not partial byte count. > > You are referring to sa(4)? Yes. > > 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). > The problem found when running under pthreads on 4.8-stable [i.e. > EOT is not returned to the application code] is not found with libkse > on 5.1-current. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309180745410.24282-100000>