Re: write(2) fails for large sizes in 64 bit applications
Re: write(2) fails for large sizes in 64 bit applications
- Subject: Re: write(2) fails for large sizes in 64 bit applications
- From: Robert Homann <email@hidden>
- Date: Thu, 4 Jun 2009 13:32:44 +0200 (MEST)
On Tue, 2 Jun 2009, Terry Lambert wrote:
> On Jun 2, 2009, at 5:37 AM, Quinn <email@hidden> wrote:
Hi!
> Our change control process will not allow us to make arbitrary changes
> or commit time to doing work without some type of bug report or
> project attachment. It's very customer focussed. People can complain
> about things on mailing lists all they want, but unless someone writes
> up a bug, that's all they've done.
OK, this is reasonable. Thank you for your insightful explanations on the
bug reporting process.
> This particular problem itself, though, is a bad example of something
> to argue passionately about, since the cause is understood, it's
> easily avoided, the operations in question are practically absurdly
> large, and the consequences of making the operations "work" will be
> large I/O stalls as the I/O request gets saturated at the disk, whose
> firmware doesn't allow the kernel driver to reorder in-flight requests
> based on later higher priority requests (i.e. the hardware itself is
> uncooperative with background I/O).
Well, INT_MAX+1 is absurdly large, but INT_MAX is not? ;-)
But I understand what you mean. An application should be playing nice when
doing I/O, and not claim the whole bandwidth for itself. Nevertheless, I'd
consider this to be an optimization to fulfull an operating system's
policy. Alternatively, the kernel could force applications to be nice by
writing only as much as the kernel likes to; this might, of course,
involve breaking applications that are broken anyway (not checking return
values etc.).
Anyway, thank you again for all the information. I will keep these in mind
when writing/porting software for/to OS X.
Best regards,
Robert Homann
--
Windows is not the answer.
Windows is the question.
The answer is "No".
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden