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

[Xavier Mendez]

El 30/11/15 a les 16:26, Paul Davis ha escrit:
>
>
> On Mon, Nov 30, 2015 at 9:30 AM, Robin Gareus <robin at gareus.org
> <mailto:robin at 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.

The FD is not expected to be a file, but a stream socket or a pipe.
But I understand there will be locks as well.

>      > 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.

Ok, all clear now. I'll use another worker thread, perform blocking I/O 
and write to a ringbuffer.

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

Good point.