Date: Sun, 7 Sep 2003 12:32:12 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Dan Langille <dan@langille.org> Cc: Nate Lawson <nate@root.org> Subject: Re: comments on proposed uthread_write.c changes Message-ID: <Pine.GSO.4.10.10309071218420.11986-100000@pcnet5.pcnet.com> In-Reply-To: <20030907110314.U78699@xeon.unixathome.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309071218420.11986-100000>