comments on proposed uthread_write.c changes

[Kern Sibbald]

On Wed, 2003-09-10 at 15:34, Daniel Eischen wrote:
> On 10 Sep 2003, Kern Sibbald wrote:
> 
> > Hello,
> > 
> > On Wed, 2003-09-10 at 02:34, Garrett Wollman wrote:
> > > <<On Tue, 9 Sep 2003 19:46:12 -0400 (EDT), Daniel Eischen <eischen at vigrid.com> said:
> > > 
> > > >   Libc_r's write treats a return of 0 from __sys_write() as a
> > > >   partial write and continues looping.
> > > 
> > > This is a bug.  The Standard is quite clear that a write of zero bytes
> > > is not possible unless the supplied buffer length is zero.  In the
> > > specific case of non-blocking files, if data might be written but
> > > doing so would cause the calling thread to block, write() must return
> > > -1 with errno set to [EAGAIN]; it may not return zero.  Therefore, a
> > > zero return from write() always indicates a permanent condition.
> > > 
> > > -GAWollman
> > 
> > Can you explain how you came to the conclusion that a non-zero
> > write may not return zero?  Keep in mind that from the
> > user's or my standpoint, we are talking about blocking
> > writes.
> 
> He saying that it is an exception and should be returned
> as such to the caller.

Thanks, sorry I completely misunderstood.

Dan has now installed FreeBSD 5 and libkse.  The test
program runs fine.  However, I just built Bacula with
libkse. The first "trivial" regression test 
backs up the Bacula build tree and then restores it.
The backup went OK (at least without erring), the
restore hung, and it is repeatable.
Needless to say, that isn't good.

Conclusion: I hope we find a fix to the current pthreads
code since it has functioned perfectly for a long time
now with the exception of the zero return value.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-standards/attachments/20030910/cc76b924/attachment.bin