[PATCH] : libc_r/uthread/uthread_write.c

[Daniel Eischen]

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