apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Huelsmann" <ehu...@gmail.com>
Subject Fix writing large chunks to consoles/pipes
Date Wed, 21 Mar 2007 09:51:25 GMT
There's a thread about fixing some issue in Subversion w.r.t. writing
large amounts of data to a console handle.

This issue is an example of a broader issue: Windows doesn't support
arbitrary amounts of data to be written to all of its handle types.
Smaller writes *are* supported, but it doesn't automatically fall back
to smaller writes when the underlaying handle only supports small
writes.

I'd say the apr_file_write() API allows for partial writes, meaning
the internals on Windows can compensate for the behaviour in Windows
(by falling back to smaller writes when detecting certain error return
codes).

There were a number of patches contributed until now, with the
following properties (please correct me if I'm wrong or incomplete):

1) Split all writes into 'always supported' smaller writes
2) Split writes for handles with specific numbers into 'always
supported' smaller writes
3) Fall back to a buffered file once the condition has been detected
which signals this kind of problem
4) Fall back to a small write (once) when detecting this condition,
returning an incomplete write

(1) was rejected because the increased performance on 'other' handles
must be an OS issue not to be worked around in a portability layer
(2) was rejected, because it doesn't solve the issue when other handle
numbers are of the same class
(3) Wasn't rejected (yet?), but feels wrong to me: an unbuffered file
was created, then it should probably stay unbuffered (since starting
to buffer will change the behavior of the file significantly on
smaller writes)
(4) Was rejected because the same condition was detected over and over
again, resulting in too many failed OS calls.

Patch #4 can be easily extended to cache the result of the fallback in
the file structure. Would that be enough to get this change committed
/ issue resolved?

If not, what more would you expect?

bye,

Erik.

Mime
View raw message