All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@shadowen.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] use xread where we are not checking for EAGAIN/EINTR
Date: Fri, 05 Jan 2007 12:20:00 +0000	[thread overview]
Message-ID: <459E4270.9090307@shadowen.org> (raw)
In-Reply-To: <7vvejlg1pg.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:
> Andy Whitcroft <apw@shadowen.org> writes:
> 
>>     We have an xread() wrapper to help us with those nasty
>>     interrupt returns and yet we fail to use it consistently.
>>     This patch updates those plain read()'s which do not
>>     have any handling for errors, or which treat those errors
>>     as user visible fatal errors.
>>
>>     This feels right to me, but perhaps there is some good
>>     reason that things are done this way ... if so could
>>     someone elighten me.
> 
> Thanks.
> 
> I do not think any of the changes you did introduced new bugs,
> but I think some of them are still wrong.  xread() protects us
> from EINTR happening before any byte is read, but it can still
> give a short read.  Many callers have a loop like this:
> 
> 	do {
>         	size = xread(...);
>                 yet_to_go -= size;
> 	} while (yet_to_go);
> 
> but some are not (e.g. add_excludes_from_file_1() in dir.c
> expects xread() does not return before reading full buffer).

Yes, that is true.  I was going to fix that in the next step with the
writes.  But yes thats likely to involve them becoming 'read_in_full'
style thing and in fact churn us more.

Ignore this one and I'll look to do it 'right'.

-apw

  reply	other threads:[~2007-01-05 12:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-05 10:54 [PATCH] use xread where we are not checking for EAGAIN/EINTR Andy Whitcroft
2007-01-05 11:19 ` Junio C Hamano
2007-01-05 12:20   ` Andy Whitcroft [this message]
2007-01-08 15:56     ` Andy Whitcroft
2007-01-08 15:57       ` [PATCH 1/4] short i/o: clean up the naming for the write_{in,or}_xxx family Andy Whitcroft
2007-01-08 15:58       ` [PATCH 2/4] short i/o: fix calls to read to use xread or read_in_full Andy Whitcroft
2007-01-08 15:58       ` [PATCH 3/4] short i/o: fix calls to write to use xwrite or write_in_full Andy Whitcroft
2007-01-08 15:58       ` [PATCH 4/4] short i/o: fix config updates to use write_in_full Andy Whitcroft
2007-01-08 20:13       ` [PATCH] use xread where we are not checking for EAGAIN/EINTR Junio C Hamano
2007-01-11 21:43       ` [PATCH] Avoid errors and warnings when attempting to do I/O on zero bytes Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=459E4270.9090307@shadowen.org \
    --to=apw@shadowen.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.