[Jack-Devel] Non-blocking I/O in process callback
me at jmendeth.com
Mon Nov 30 17:01:50 CET 2015
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
> > 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.
More information about the Jackaudio