[flac-dev] Windows file buffering

[lvqcl]

Erik de Castro Lopo wrote:
> lvqcl,
>
> Would you be able to have alook at this one? I think its
> Windows related:
>
>     https://sourceforge.net/p/flac/feature-requests/114/
>

The relevant changes are
<http://git.xiph.org/?p=flac.git;a=commitdiff;h=6a6207b52a86b1d7980a5233e297c0fc948bed7d> and
<http://git.xiph.org/?p=flac.git;a=commitdiff;h=e8632477774f56b4fe7ccab525cad2ceab244b8a>

the current code:

#ifdef _WIN32
     /*
      * Windows can suffer quite badly from disk fragmentation. This can be
      * reduced significantly by setting the output buffer size to be 10MB.
      */
     setvbuf(file, NULL, _IOFBF, 10*1024*1024);
#endif


LRN <lrn1986 at gmail.com> wrote:

> The commit mentioned in the feature request should not cause such
> behaviour, as it only does short-lived operations (opens a file, does
> stuff, closes the file immediately after) and is clearly distinguishing
> between disk files and pipes (which is how you, presumably, stream data to
> other processes for whatever reasons).
>
> I don't claim that FLAC doesn't do buffering, as the OP described, just
> that this commit is unlikely to be the cause.

Maybe you mean some other commit? For example,
<http://git.xiph.org/?p=flac.git;a=commitdiff;h=d66f6754bf94bc8ba23d3579d0b5650cd380c9f0> ?
Because setvbuf() should definitely change libFLAC behaviour regardless of files/pipes/etc.


The attached patch *should* resolve the issue. libFLAC will call setvbuf(file, ...)
only if GetFileType(...file...) == FILE_TYPE_DISK.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buffering.patch
Type: application/octet-stream
Size: 615 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20151210/c3bffdd5/attachment.obj