From owner-freebsd-standards@FreeBSD.ORG Mon Sep 8 11:01:44 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30CD116A4C0 for ; Mon, 8 Sep 2003 11:01:44 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80E0A43FAF for ; Mon, 8 Sep 2003 11:01:38 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h88I1cUp096955 for ; Mon, 8 Sep 2003 11:01:38 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h88I1bd3096949 for freebsd-standards@freebsd.org; Mon, 8 Sep 2003 11:01:37 -0700 (PDT) Date: Mon, 8 Sep 2003 11:01:37 -0700 (PDT) Message-Id: <200309081801.h88I1bd3096949@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2003 18:01:44 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2001/01/23] misc/24590 standards timezone function not compatible witn Sin o [2002/02/25] bin/35307 standards standard include files are not standard c o [2003/03/05] bin/48958 standards The type 'bool' has different sizes for C o [2003/04/21] standards/51209standards [PATCH] add a64l()/l64a/l64a_r functions p [2003/06/05] standards/52972standards /bin/sh arithmetic not POSIX compliant o [2003/06/20] standards/53554standards interval timers not cleared in fork() o [2003/07/12] standards/54410standards one-true-awk not POSIX compliant (no exte 7 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi o [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant s [2002/03/18] standards/36076standards Implementation of POSIX fuser command o [2002/06/13] standards/39256standards [v]snprintf aren't POSIX-conformant for s o [2002/07/09] misc/40378 standards stdlib.h gives needless warnings with -an p [2002/07/16] standards/40669standards command command does not support `-p' opt p [2002/08/12] standards/41576standards POSIX compliance of ln(1) o [2002/10/23] standards/44425standards getcwd() succeeds even if current dir has o [2002/12/09] standards/46119standards Priority problems for SCHED_OTHER using p o [2002/12/23] standards/46504standards Warnings in headers o [2003/04/22] standards/51292standards [PATCH] add ecvt()/fcvt()/gcvt() function o [2003/06/22] standards/53613standards FreeBSD doesn't define EPROTO o [2003/06/24] bin/53682 standards [PATCH] add fuser(1) utitity o [2003/07/24] standards/54809standards pcvt deficits o [2003/07/24] standards/54833standards more pcvt deficits o [2003/07/25] standards/54839standards pcvt deficits o [2003/09/04] standards/56476standards cd9660 unicode support simple hack 17 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Sep 8 11:04:05 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB1FD16A4BF for ; Mon, 8 Sep 2003 11:04:05 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1B6744020 for ; Mon, 8 Sep 2003 11:03:13 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h88I3DUp098907 for ; Mon, 8 Sep 2003 11:03:13 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h88I3CAi098901 for standards@freebsd.org; Mon, 8 Sep 2003 11:03:12 -0700 (PDT) Date: Mon, 8 Sep 2003 11:03:12 -0700 (PDT) Message-Id: <200309081803.h88I3CAi098901@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: standards@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2003 18:04:05 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/08/18] kern/29844 standards [PATCH] setpgrp does not behave as manual 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [1995/01/11] i386/105 standards Distributed libm (msun) has non-standard o [2000/09/24] bin/21519 standards sys/dir.h should be deprecated some more o [2000/12/05] kern/23304 standards POSIX clock_gettime, clock_getres return s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public 4 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue Sep 9 16:46:21 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD07F16A4D5 for ; Tue, 9 Sep 2003 16:46:21 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A52743FEA for ; Tue, 9 Sep 2003 16:46:21 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h89NkCtp016181; Tue, 9 Sep 2003 19:46:13 -0400 (EDT) Date: Tue, 9 Sep 2003 19:46:12 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Dan Langille In-Reply-To: <3F5B89B3.11367.112C1E2D@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Kern Sibbald cc: Dan Nelson cc: freebsd-standards@FreeBSD.org cc: Nate Lawson Subject: Re: comments on proposed uthread_write.c changes X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@FreeBSD.org List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2003 23:46:22 -0000 [ Redirected to -standards ] Synopsis: libc_r wraps write() and changes a blocking file descriptor to non-blocking behind the scenes. When __sys_write() returns less than the number of bytes requested, libc_r's write() continues looping trying to finish the requested write. Problem: A return of 0 for a write() to a tape device means end-of-file. Libc_r's write treats a return of 0 from __sys_write() as a partial write and continues looping. The end-of-file is passed and a few more blocks may be written before the physical end-of-tape is reached. [ In this context, end-of-file means a the shiny end-of-tape marker on the tape (at least that's what it looks like on 7 & 9 track tapes -- am I dating myself?). It doesn't mean an EOF marker. ] I've been reading the POSIX spec in regards to write(): http://www.opengroup.org/onlinepubs/007904975/toc.htm particularly the Rationale at the end. I think it is OK for libc_r to special case a return of 0 from __sys_write() and pass it back to the caller. Any comments? On Sun, 7 Sep 2003, Dan Langille wrote: > On 7 Sep 2003 at 12:32, Daniel Eischen wrote: > > > On Sun, 7 Sep 2003, Dan Langille wrote: > > > > > A problem with pthreads and EOT has been identified. See PR 56274. It > > > was suggested the solution was probably just a matter of changing one of > > > the >0 tests to >=0 in uthread_write.c > > > > > > Any comments on that? > > > > I don't know that a return of 0 isn't valid for other devices. > > If this is the case, a return of 0 for blocking writes may break > > other applications. > > > > The patch isn't quite correct (at least looking at -current srcs). > > Lines 98-99 are: > > > > if (blocking && ((n < 0 && (errno == EWOULDBLOCK || > > errno == EAGAIN)) || (n >= 0 && num < nbytes))) { > > > > This will get entered first if n == 0, and I don't think your > > proposed patch would have any effect. I think you would have > > to change the "n >= 0" above to be "n > 0" in conjunction with > > your patch. > > Ahh thank you. That explains why the test results with the original > patch did not differ from -STABLE or 5.1-RELEASE. After adding your > suggestions, we have had success. > > The points to note: > > 1. The status that stopped the writing was 0 > 2. It wrote 17,256 blocks, and read 17,256 blocks. > > Point 1 is key to determining EOT. Point 2 is what you always want > to have... > > [dan@undef:~/tape-test] $ sudo ./tapetest /dev/nsa0 > *rewind > Rewound /dev/nsa0 > *rawfill > Begin writing blocks of 64512 bytes. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++ > weof_dev > Wrote EOF to /dev/nsa0 > Write failed. Last block written=17256. stat=0 ERR=Unknown error: 0 > *rewind > Rewound /dev/nsa0 > *scan > Starting scan at file 0 > 17256 blocks of 64512 bytes in file 0 > End of File mark. > End of File mark. > End of tape > Total files=1, blocks=17256, bytes = 1113219072 > * > > > This could be solved at the application level by selecting on > > the tape device and performing non-blocking writes to it. Since > > the application knows that a return of 0 is end-of-tape, it > > must also know the difference between talking to a tape device > > and talking to a regular file, socket, etc. > > True. But *if* the code is wrong, it should be fixed. > > FWIW, the patch follows. As always, opinions and suggestions are > welcome. > > --- uthread_write.c.org Sun Sep 7 10:58:31 2003 > +++ uthread_write.c Sun Sep 7 15:41:34 2003 > @@ -93,7 +93,7 @@ > * write: > */ > if (blocking && ((n < 0 && (errno == EWOULDBLOCK || > - errno == EAGAIN)) || (n >= 0 && num < nbytes))) { > + errno == EAGAIN)) || (n > 0 && num < nbytes))) { > curthread->data.fd.fd = fd; > _thread_kern_set_timeout(NULL); > > @@ -131,7 +131,7 @@ > * If there was an error, return partial success > * (if any bytes were written) or else the error: > */ > - } else if (n < 0) { > + } else if (n <= 0) { > if (num > 0) > ret = num; > else > > -- > Dan Langille : http://www.langille.org/ > -- Dan Eischen From owner-freebsd-standards@FreeBSD.ORG Tue Sep 9 17:34:37 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C44F516A4BF; Tue, 9 Sep 2003 17:34:37 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id C86D143FBF; Tue, 9 Sep 2003 17:34:36 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost.nic.fr [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h8A0YTXV066681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Tue, 9 Sep 2003 20:34:30 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h8A0YTdY066678; Tue, 9 Sep 2003 20:34:29 -0400 (EDT) (envelope-from wollman) Date: Tue, 9 Sep 2003 20:34:29 -0400 (EDT) From: Garrett Wollman Message-Id: <200309100034.h8A0YTdY066678@khavrinen.lcs.mit.edu> To: deischen@freebsd.org In-Reply-To: References: <3F5B89B3.11367.112C1E2D@localhost> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: Dan Nelson cc: Nate Lawson cc: Kern Sibbald cc: Dan Langille cc: freebsd-standards@freebsd.org Subject: Re: comments on proposed uthread_write.c changes X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2003 00:34:37 -0000 < 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 From owner-freebsd-standards@FreeBSD.ORG Tue Sep 9 17:46:12 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 636FD16A4BF for ; Tue, 9 Sep 2003 17:46:12 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0628143F75 for ; Tue, 9 Sep 2003 17:46:09 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h8A0k2tp028583; Tue, 9 Sep 2003 20:46:02 -0400 (EDT) Date: Tue, 9 Sep 2003 20:46:02 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Garrett Wollman In-Reply-To: <200309100034.h8A0YTdY066678@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Dan Nelson cc: Nate Lawson cc: Kern Sibbald cc: Dan Langille cc: freebsd-standards@freebsd.org Subject: Re: comments on proposed uthread_write.c changes X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2003 00:46:12 -0000 On Tue, 9 Sep 2003, Garrett Wollman wrote: > < 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. Thanks. Dan (Langille), go ahead and commit the fix to -current if you'd like. -- Dan Eischen From owner-freebsd-standards@FreeBSD.ORG Wed Sep 10 00:19:57 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDF5C16A4BF; Wed, 10 Sep 2003 00:19:57 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7797043FBF; Wed, 10 Sep 2003 00:19:55 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h8A7JhE30153; Wed, 10 Sep 2003 09:19:43 +0200 From: Kern Sibbald To: Garrett Wollman In-Reply-To: <200309100034.h8A0YTdY066678@khavrinen.lcs.mit.edu> References: <3F5B89B3.11367.112C1E2D@localhost> <200309100034.h8A0YTdY066678@khavrinen.lcs.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dQwOkbSDWJuqMz0oqlSu" Organization: Message-Id: <1063178382.15482.550.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 10 Sep 2003 09:19:43 +0200 cc: deischen@freebsd.org cc: freebsd-standards@freebsd.org cc: Dan Nelson cc: Dan Langille cc: Nate Lawson Subject: Re: comments on proposed uthread_write.c changes X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2003 07:19:57 -0000 --=-dQwOkbSDWJuqMz0oqlSu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, On Wed, 2003-09-10 at 02:34, Garrett Wollman wrote: > < said: >=20 > > Libc_r's write treats a return of 0 from __sys_write() as a > > partial write and continues looping. >=20 > 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. >=20 > -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. In reading the standard, the paragraph cited below permits a zero to be returned.=20 If a write() requests that more bytes be written than there is room for (for example, [XSI] [Option Start] the process' file size limit =20 or [Option End] the physical end of a medium), only as many bytes as there is room for shall be written. Best regards, --=-dQwOkbSDWJuqMz0oqlSu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/XtCONgfoSvWqwEgRApwFAJ94WujQGeGZzrHVrW/qCZt7P8wIUwCgtzsF SNJ4mzYtOq/Jzhvrq+JK7F8= =Y3zY -----END PGP SIGNATURE----- --=-dQwOkbSDWJuqMz0oqlSu-- From owner-freebsd-standards@FreeBSD.ORG Wed Sep 10 06:34:23 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA33316A4BF for ; Wed, 10 Sep 2003 06:34:23 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E83F443F3F for ; Wed, 10 Sep 2003 06:34:22 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h8ADYHtp006688; Wed, 10 Sep 2003 09:34:17 -0400 (EDT) Date: Wed, 10 Sep 2003 09:34:17 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Kern Sibbald In-Reply-To: <1063178382.15482.550.camel@rufus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@freebsd.org cc: Nate Lawson cc: Dan Nelson cc: Dan Langille Subject: Re: comments on proposed uthread_write.c changes X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2003 13:34:23 -0000 On 10 Sep 2003, Kern Sibbald wrote: > Hello, > > On Wed, 2003-09-10 at 02:34, Garrett Wollman wrote: > > < 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. -- Dan Eischen From owner-freebsd-standards@FreeBSD.ORG Wed Sep 10 06:55:14 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 875F716A4BF; Wed, 10 Sep 2003 06:55:14 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 426DB43FDD; Wed, 10 Sep 2003 06:55:12 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h8ADtBE31227; Wed, 10 Sep 2003 15:55:11 +0200 From: Kern Sibbald To: deischen@freebsd.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ojI6Dm1Z7wsvZ6m2tnfi" Organization: Message-Id: <1063202110.27639.66.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 10 Sep 2003 15:55:10 +0200 cc: freebsd-standards@freebsd.org cc: Nate Lawson cc: Dan Nelson cc: Dan Langille Subject: Re: comments on proposed uthread_write.c changes X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2003 13:55:14 -0000 --=-ojI6Dm1Z7wsvZ6m2tnfi Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-09-10 at 15:34, Daniel Eischen wrote: > On 10 Sep 2003, Kern Sibbald wrote: >=20 > > Hello, > >=20 > > On Wed, 2003-09-10 at 02:34, Garrett Wollman wrote: > > > < said: > > >=20 > > > > Libc_r's write treats a return of 0 from __sys_write() as a > > > > partial write and continues looping. > > >=20 > > > This is a bug. The Standard is quite clear that a write of zero byte= s > > > 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. > > >=20 > > > -GAWollman > >=20 > > 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. >=20 > 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=20 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. --=-ojI6Dm1Z7wsvZ6m2tnfi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/Xy0+NgfoSvWqwEgRAtwaAKCgn+YfayeKNOoXNva/+Mb8v93i5ACdF/i6 awVGm6OBvXuxfBx8DB82lv0= =yTpg -----END PGP SIGNATURE----- --=-ojI6Dm1Z7wsvZ6m2tnfi-- From owner-freebsd-standards@FreeBSD.ORG Wed Sep 10 07:53:28 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C228216A4BF; Wed, 10 Sep 2003 07:53:28 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C02843FD7; Wed, 10 Sep 2003 07:53:25 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost.nic.fr [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h8AErJXV078353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Wed, 10 Sep 2003 10:53:20 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h8AErJsV078350; Wed, 10 Sep 2003 10:53:19 -0400 (EDT) (envelope-from wollman) Date: Wed, 10 Sep 2003 10:53:19 -0400 (EDT) From: Garrett Wollman Message-Id: <200309101453.h8AErJsV078350@khavrinen.lcs.mit.edu> To: Kern Sibbald In-Reply-To: <1063178382.15482.550.camel@rufus> References: <3F5B89B3.11367.112C1E2D@localhost> <200309100034.h8A0YTdY066678@khavrinen.lcs.mit.edu> <1063178382.15482.550.camel@rufus> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: deischen@freebsd.org cc: freebsd-standards@freebsd.org cc: Dan Nelson cc: Dan Langille cc: Nate Lawson Subject: Re: comments on proposed uthread_write.c changes X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2003 14:53:28 -0000 < said: > 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. That is not my conclusion. My conclusion is that, if write() returns zero, it must be a permanent condition; that is to say, when write() returns zero it is not appropriate to retry, as one would do for a partial write of non-zero length. -GAWollman From owner-freebsd-standards@FreeBSD.ORG Wed Sep 10 08:40:33 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D519316A4BF; Wed, 10 Sep 2003 08:40:33 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFCE543FE5; Wed, 10 Sep 2003 08:40:31 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h8AFeNE31532; Wed, 10 Sep 2003 17:40:23 +0200 From: Kern Sibbald To: Garrett Wollman In-Reply-To: <200309101453.h8AErJsV078350@khavrinen.lcs.mit.edu> References: <3F5B89B3.11367.112C1E2D@localhost> <200309100034.h8A0YTdY066678@khavrinen.lcs.mit.edu> <1063178382.15482.550.camel@rufus> <200309101453.h8AErJsV078350@khavrinen.lcs.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xmwi4T7h8ZoAwEEUyMKV" Organization: Message-Id: <1063208423.27638.122.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 10 Sep 2003 17:40:23 +0200 cc: deischen@freebsd.org cc: freebsd-standards@freebsd.org cc: Dan Nelson cc: Dan Langille cc: Nate Lawson Subject: Re: comments on proposed uthread_write.c changes X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2003 15:40:34 -0000 --=-xmwi4T7h8ZoAwEEUyMKV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-09-10 at 16:53, Garrett Wollman wrote: > < said: >=20 > > 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. >=20 > That is not my conclusion. My conclusion is that, if write() returns > zero, it must be a permanent condition; that is to say, when write() > returns zero it is not appropriate to retry, as one would do for a > partial write of non-zero length. >=20 > -GAWollman Yes, sorry, I misunderstood -- my mistake. --=-xmwi4T7h8ZoAwEEUyMKV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/X0XnNgfoSvWqwEgRAgkJAJ4+6DbMBK2tcB/fSvIatR/8CeZy4gCffdav YvnclT6lF4B81lFQGEPe2Jg= =Hvhr -----END PGP SIGNATURE----- --=-xmwi4T7h8ZoAwEEUyMKV--