From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: "Steffen Prohaska" <prohaska@zib.de>,
"Git List" <git@vger.kernel.org>, "Johannes Sixt" <j6t@kdbg.org>,
"John Keeping" <john@keeping.me.uk>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"Kyle J. McKay" <mackyle@gmail.com>,
"Torsten Bögershausen" <tboegi@web.de>
Subject: Re: [PATCH v3] compat: Fix read() of 2GB and more on Mac OS X
Date: Mon, 19 Aug 2013 09:33:04 -0700 [thread overview]
Message-ID: <7veh9pmyin.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAPig+cTr_B+vtN4sFzepWeW4TpRPD9eKnjy08yJ2pf3KfVU1XA@mail.gmail.com> (Eric Sunshine's message of "Mon, 19 Aug 2013 09:59:57 -0400")
Eric Sunshine <sunshine@sunshineco.com> writes:
>> +# Define NEEDS_CLIPPED_READ if your read(2) cannot read more than
>> +# INT_MAX bytes at once (e.g. MacOS X).
>> +#
>> # Define NEEDS_CLIPPED_WRITE if your write(2) cannot write more than
>> # INT_MAX bytes at once (e.g. MacOS X).
>
> Is it likely that we would see a platform requiring only one or the
> other CLIPPED? Would it make sense to combine these into a single
> NEEDS_CLIPPED_IO?
I am slightly negative to that suggestion for two reasons.
- Does MacOS X clip other IO operations? Do we need to invent yet
another NEEDS_CLIPPED, e.g. NEEDS_CLIPPED_LSEEK?
A single NEEDS_CLIPPED_IO may sound attractive for its simplicity
(e.g. on a system that only needs NEEDS_CLIPPED_WRITE, we will
unnecessarily chop a big read into multiple reads, but that does
not affect the correctness of the operation, only performance but
the actual IO cost will dominate it anyway). If we know there
are 47 different IO operations that might need clipping, that
simplicity is certainly a good thing to have. I somehow do not
think the set of operations will grow that large, though.
- NEEDS_CLIPPED_IO essentially says "only those who clip their
writes would clip their reads (and vice versa)", which is not all
that different from saying "only Apple would clip their IO",
which in turn defeats the notion of "let's use a generic
NEEDS_CLIPPED without limiting the workaround to specific
platforms" somewhat.
next prev parent reply other threads:[~2013-08-19 16:33 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-17 12:40 [PATCH] xread(): Fix read error when filtering >= 2GB on Mac OS X Steffen Prohaska
2013-08-17 15:27 ` John Keeping
2013-08-17 15:56 ` Torsten Bögershausen
2013-08-17 17:16 ` Johannes Sixt
2013-08-17 18:57 ` Jonathan Nieder
2013-08-17 20:25 ` Kyle J. McKay
2013-08-17 21:23 ` Jonathan Nieder
2013-08-19 6:38 ` [PATCH v2] compat: Fix read() of 2GB and more " Steffen Prohaska
2013-08-19 7:54 ` John Keeping
2013-08-19 8:20 ` Steffen Prohaska
2013-08-19 8:20 ` Johannes Sixt
2013-08-19 8:25 ` Stefan Beller
2013-08-19 8:40 ` Johannes Sixt
2013-08-19 8:28 ` Steffen Prohaska
2013-08-19 8:21 ` [PATCH v3] " Steffen Prohaska
2013-08-19 13:59 ` Eric Sunshine
2013-08-19 16:33 ` Junio C Hamano [this message]
2013-08-19 15:41 ` [PATCH v4] " Steffen Prohaska
2013-08-19 16:04 ` Linus Torvalds
2013-08-19 16:37 ` Steffen Prohaska
2013-08-19 17:24 ` Junio C Hamano
2013-08-19 17:16 ` Junio C Hamano
2013-08-19 17:28 ` Linus Torvalds
2013-08-19 21:56 ` Kyle J. McKay
2013-08-19 22:51 ` Linus Torvalds
2013-08-27 4:59 ` Junio C Hamano
2013-08-20 6:43 ` [PATCH v5 0/2] Fix IO of >=2GB on Mac OS X by limiting IO chunks Steffen Prohaska
2013-08-20 6:43 ` [PATCH v5 1/2] xread, xwrite: Limit size of IO, fixing IO of 2GB and more on Mac OS X Steffen Prohaska
2013-08-20 19:37 ` Junio C Hamano
2013-08-21 19:50 ` Torsten Bögershausen
2013-08-20 6:43 ` [PATCH v5 2/2] Revert "compate/clipped-write.c: large write(2) fails on Mac OS X/XNU" Steffen Prohaska
2013-08-21 13:46 ` [PATCH v6 0/2] Fix IO >= 2GB on Mac, fixed typo Steffen Prohaska
2013-08-21 13:46 ` [PATCH v5 1/2] xread, xwrite: Limit size of IO, fixing IO of 2GB and more on Mac OS X Steffen Prohaska
2013-08-21 13:46 ` [PATCH v5 2/2] Revert "compate/clipped-write.c: large write(2) fails on Mac OS X/XNU" Steffen Prohaska
2013-08-21 15:58 ` [PATCH v6 0/2] Fix IO >= 2GB on Mac, fixed typo Junio C Hamano
2013-08-19 8:27 ` [PATCH v2] compat: Fix read() of 2GB and more on Mac OS X Johannes Sixt
2013-08-19 14:41 ` Torsten Bögershausen
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7veh9pmyin.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=john@keeping.me.uk \
--cc=jrnieder@gmail.com \
--cc=mackyle@gmail.com \
--cc=prohaska@zib.de \
--cc=sunshine@sunshineco.com \
--cc=tboegi@web.de \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).