14 Jun
2011
14 Jun
'11
9:09 a.m.
To me that suggests that either you have a completely
unique
problem to solve or that they are other solutions to your
problem that other people use to get around the same problem.
My guess is that your problem is not completely unique.
Certainly not unique. My guess is that nobody worried about a
(possibly small) performance penalty, and instead used simpler
strategies -- or they weren't using sndfile in the first place.
Consider this: for any request size you choose, NOT cancelling could
double your latency in the worst case if you're streaming from a slow
NFS server.
Now, I've been able to implement my strategy by storing fd's and using
sf_open_fd() as necessary. I.e. after a thread is cancelled in the
middle of I/O (rendering the SNDFILE invalid), I re-open fd's using
sf_open_fd().
This begs a question -- is it possible to "reset" the SNDFILE less
dramatically? E.g. would a seek back to offset 0, or a pair of seeks,
or some other trick also reset the data structures? If not, it might
be nice to add a sf_reset() function or a SF_RESET sf_command()
parameter.
On second
thought, though, this proposal could not possibly work
without a userspace (libsndfile) cache, because read() might return
incomplete frames, which would need to be processed in a later call.
Modifying libsndfile to do fread/fwrite style buffering would be