[flac-dev] Windows file buffering
lrn1986 at gmail.com
Thu Dec 10 11:08:37 PST 2015
On 10.12.2015 19:58, lvqcl wrote:
> LRN 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> ?
Yes, that is exactly what i meant.
> The attached patch *should* resolve the issue. libFLAC will call setvbuf(file, ...)
> only if GetFileType(...file...) == FILE_TYPE_DISK.
That patch looks correct. That said, i'm not sure why there's setvbuf() in
the first place. I mean, the code to de-fragment the output file already
exists (the aforementioned d66f675), so why buffering? Was it proven
empirically that buffering is required? Or am i looking at this backwards
and that code was added later than setvbuf()?
O< ascii ribbon - stop html email! - www.asciiribbon.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20151210/58e8f466/attachment-0001.pgp
More information about the flac-dev