From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 7 09:32:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FE8616A4BF for ; Sun, 7 Sep 2003 09:32:19 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D53CB44005 for ; Sun, 7 Sep 2003 09:32:17 -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 h87GWCtp014178; Sun, 7 Sep 2003 12:32:12 -0400 (EDT) Date: Sun, 7 Sep 2003 12:32:12 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Dan Langille In-Reply-To: <20030907110314.U78699@xeon.unixathome.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@FreeBSD.org cc: Dan Nelson cc: Kern Sibbald cc: Nate Lawson Subject: Re: comments on proposed uthread_write.c changes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2003 16:32:19 -0000 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. I cannot comment on whether returns of 0 for blocking writes are valid in some cases or not. I would tend to be very careful because it's not something that is easily tested by running thread regression tests, kde, etc. 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. -- Dan Eischen