Re: [Jack-Devel] Non-blocking I/O in process callback

On Mon, Nov 30, 2015 at 9:30 AM, Robin Gareus &lt;robin(a)gareus.org <mailto: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.

threads simplify the 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.

Keep jack freewheeling in mind. When freewheeling the process callback needs to wait for i/o to complete.