From: Andy Whitcroft <apw@shadowen.org>
To: Junio C Hamano <junkio@cox.net>
Cc: Andy Whitcroft <apw@shadowen.org>, git@vger.kernel.org
Subject: Re: [PATCH] use xread where we are not checking for EAGAIN/EINTR
Date: Mon, 08 Jan 2007 15:56:15 +0000 [thread overview]
Message-ID: <45A2699F.5060100@shadowen.org> (raw)
In-Reply-To: <459E4270.9090307@shadowen.org>
[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]
Andy Whitcroft wrote:
> 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'.
Ok, after much hacking about I think I've got something sensible sorted
out for this. Following this email are four patches which convert the
various read/write/xread/xwrite users over to xread/read_in_full and
xwrite/write_in_full as appropriate. Its pretty invasive as obviously
I/O is pretty common in an SCM.
next with this stack passes the builtin test suite. I additionally used
the attached patch to induce severe short read/write semantics. Before
this patch series git was _very_ unhappy, unable to even create a
repository.
This series is against next.
-apw
[-- Attachment #2: PATCH --]
[-- Type: text/plain, Size: 688 bytes --]
diff --git a/git-compat-util.h b/git-compat-util.h
index 55456da..931cbed 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -210,6 +210,7 @@ static inline void *xmmap(void *start, size_t length,
static inline ssize_t xread(int fd, void *buf, size_t len)
{
ssize_t nr;
+ if (len > 5) len = 5;
while (1) {
nr = read(fd, buf, len);
if ((nr < 0) && (errno == EAGAIN || errno == EINTR))
@@ -221,6 +222,7 @@ static inline ssize_t xread(int fd, void *buf, size_t len)
static inline ssize_t xwrite(int fd, const void *buf, size_t len)
{
ssize_t nr;
+ if (len > 5) len = 5;
while (1) {
nr = write(fd, buf, len);
if ((nr < 0) && (errno == EAGAIN || errno == EINTR))
next prev parent reply other threads:[~2007-01-08 15:56 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
2007-01-08 15:56 ` Andy Whitcroft [this message]
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=45A2699F.5060100@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.