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

[Paul Davis]

On Mon, Nov 30, 2015 at 9:30 AM, Robin Gareus <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.


>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20151130/8f486b2b/attachment.html>