[LAD] [LAU] cancelling I/O with libsndfile

[Dan Muresan]

Hi Fons,

> It's probably a Good Thing (TM) that libsndfile doesn't do its
> own buffering. First, the file system will do buffering, and if

I agree, I prefer the flexibility of implementing my own user-space
cache in an app-dependent way, too.

> exactly this is organised will be application dependent. Having
> a third layer in between this and the system is not going to help.

For sure, two user-space caches add a useless extra layer of copying.

> One way to organise the buffer is to divide it in fragments
> of say 1/4 second, and have the start offset of each one

Yes, that's exactly how my implementation works. My ringbuffer is
divided in fragments.

> quantised to the same value. The syscall overhead becomes
> trivial for such a lenght. When you need new fragments, you

Yes, that's why I argued for long requests over short ones.

> the actual read() call). The one you can't cancel is no big
> deal, just let it happen. It will take little time compared

And this is why I gave the NFS example earlier in the discussion...

What if it the data comes from the network, e.g. a streaming server
that has just 110% the bandwidth of the actual real-time playback? As
I said, in this case you almost double the latency if you can't cancel
the request.

It might be an interesting idea to do new requests in parallel with
cancelled ones, but this requires another layer of ringbuffer / memory
management.


-- Dan