30 Nov
2015
30 Nov
'15
8:26 a.m.
On Mon, Nov 30, 2015 at 9:30 AM, Robin Gareus <robin(a)gareus.org> wrote:
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.
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.
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.