On Mon, Nov 30, 2015 at 9:30 AM, Robin Gareus <robin@gareus.org> wrote:

ow can you know that no other process is using the same file?

I have not checked the underlying implementation, but I can easily
imagine that there are locks in the kernel.

more than one. there are filesystem-level locks even if you avoid per-file locks.

> Thanks for the advice, I'm currently using ringbuffers + worker threads
> but being able to do this I/O directly in process() would simplify the
> code considerably. I'll consider it, though.

you absolutely should NOT do this. even if it works for you under some conditions, it is absolutely the wrong design. no matter how you try to do it, you are moving all the data to disk from inside the process callback. non-blocking (or even async) I/O might obscure the basic problem with doing this, but obscuring it is all that it does. please don't do this.

On a different note: check async i/o performance first. Paul may chime
in later, I recall that he benchmarked single-threaded, thread-polls and
async i/o for Ardour at some point and opted for the first.

i recently re-tested this, and amazingly continued to find that with at least one test case (serially-written files, each 10MB, written round-robin), the multithreaded version was slower than the single-threaded one. multithreaded simulates non-blocking I/O by working around the defects in the async I/O API available for linux and OS X. i don't want to be too emphatic about this, because it needs more evaluation with different test cases, but it was really quite suprising to me that even that case didn't show improvement over the single-threaded, blocking case.