30 Nov
2015
30 Nov
'15
3:11 a.m.
Hello,
I'm wondering whether it's safe to do non-blocking reads or writes from
inside the process callback.
From what I've seen, non-blocking I/O doesn't cause the process to go
into blocked state, and the realtime scheduler should not switch to
another process. But the documentation doesn't seem to allow them:
[...] it cannot call functions that might block for a
long time. This
includes all I/O functions (disk, TTY, network), [...]
So, is it safe to use non-blocking I/O in the process callback?
Thank you,
Xavi
30 Nov
30 Nov
5:10 a.m.
Hi Xavi,
If the time to complete the function is deterministic, it is real time safe.
System calls (blocking ones) have "unbounded execution time", and as such
are not rt safe.
If your I/O will take a significant amount of time, I suggest offloading to
a worker thread.
Hth, -Harry
On 30 Nov 2015 11:11, "Xavier Mendez" <me(a)jmendeth.com> wrote:
Hello,
I'm wondering whether it's safe to do non-blocking reads or writes from
inside the process callback.
From what I've seen, non-blocking I/O doesn't cause the process to go into
blocked state, and the realtime scheduler should not switch to another
process. But the documentation doesn't seem to allow them:
[...] it cannot call functions that might block
for a long time. This
includes all I/O functions (disk, TTY, network), [...]
So, is it safe to use non-blocking I/O in the process callback?
Thank you,
Xavi
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
5:21 a.m.
Thanks for the quick response!
El 30/11/15 a les 14:10, Harry van Haaren ha escrit:
Hi Xavi,
If the time to complete the function is deterministic, it is real time safe.
System calls (blocking ones) have "unbounded execution time", and as
such are not rt safe.
If your I/O will take a significant amount of time, I suggest offloading
to a worker thread.
Hth, -Harry
On 30 Nov 2015 11:11, "Xavier Mendez" <me(a)jmendeth.com
<mailto:me@jmendeth.com>> wrote:
Hello,
I'm wondering whether it's safe to do non-blocking reads or writes
from inside the process callback.
From what I've seen, non-blocking I/O
doesn't cause the process to
go into blocked state, and the realtime
scheduler should not switch
to another process. But the documentation doesn't seem to allow them:
[...] it cannot call functions that might block
for a long time. This
includes all I/O functions (disk, TTY, network), [...]
So, is it safe to use non-blocking I/O in the process callback?
Thank you,
Xavi
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org <mailto:Jack-Devel@lists.jackaudio.org>
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
5:27 a.m.
On 11/30/2015 12:11 PM, Xavier Mendez wrote:
Hello,
I'm wondering whether it's safe to do non-blocking reads or writes from
inside the process callback.
From what I've seen, non-blocking I/O doesn't cause the process to go
into blocked state, and the realtime scheduler should not switch to
another process. But the documentation doesn't seem to allow them:
On which platform?
The short answer is:
"If you don’t know how long it will take, don't do it." [1]
All i/o involve syscalls, and then it depends what the kernel does for
the specific system call(s). Asynchronous I/O usually involves signals
at some point which makes it not safe to use. Some implementation also
involve mutexes to avoid resource conflicts. You'll have to check the
standard-lib and kernel source for the system that you target.
All moot anyway. Proper software needs to do error-handling and doing
that in a rt-callback is out of the question. So you need a non-realtime
thread anyway and if you have that you can directly do i/o there.
anyway, using a ringbuffer to decouple i/o is trivial: e.g.
https://github.com/jackaudio/example-clients/blob/master/capture_client.c
best,
robin
[1]
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-…
[...] it cannot call functions that might block
for a long time. This
includes all I/O functions (disk, TTY, network), [...]
So, is it safe to use non-blocking I/O in the process callback?
6 a.m.
El 30/11/15 a les 14:27, Robin Gareus ha escrit:
On 11/30/2015 12:11 PM, Xavier Mendez wrote:
This is going to run on UNIX-like systems, mostly Linux, and I'm
programming in C/C++.
Hello,
I'm wondering whether it's safe to do non-blocking reads or writes from
inside the process callback.
From what I've seen, non-blocking I/O doesn't cause the process to go
into blocked state, and the realtime scheduler should not switch to
another process. But the documentation doesn't seem to allow them:
On which platform? [...] it cannot call functions that might block
for a long time. This
includes all I/O functions (disk, TTY, network), [...]
So, is it safe to use non-blocking I/O in the process callback?
The short answer is:
"If you don’t know how long it will take, don't do it." [1]
All i/o involve syscalls, and then it depends what the kernel does for
the specific system call(s). Asynchronous I/O usually involves signals
at some point which makes it not safe to use.
I wasn't very specific, let me clarify: I'm only going to do some
read(2) or write(2) syscalls on an FD which has O_NONBLOCK set.
AFAIK these don't involve signals...
Some implementation also
involve mutexes to avoid resource conflicts. You'll have to check the
standard-lib and kernel source for the system that you target.
Hmm... Are mutexes a problem if the FD is used exclusively from the
process callback?
All moot anyway. Proper software needs to do
error-handling and doing
that in a rt-callback is out of the question. So you need a non-realtime
thread anyway and if you have that you can directly do i/o there.
Error handling is not a problem here, if those syscalls fail I'll simply
deactivate the JACK client.
anyway, using a ringbuffer to decouple i/o is trivial:
e.g.
https://github.com/jackaudio/example-clients/blob/master/capture_client.c
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.
Thank you for your help,
Xavi
6:30 a.m.
On 11/30/2015 03:00 PM, Xavier Mendez wrote:
How 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.
Keep jack freewheeling in mind. When freewheeling the process callback
needs to wait for i/o to complete.
"worker thread" sounds like LV2. In this case you're good already since
the LV2 worker takes care of 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.
El 30/11/15 a les 14:27, Robin Gareus ha escrit:
I'm pretty sure they do in the current Linux kernel. There'll be an IRQ
once the read is complete.
On 11/30/2015 12:11 PM, Xavier Mendez wrote:
This is going to run on UNIX-like systems, mostly Linux, and I'm
programming in C/C++.
Hello,
I'm wondering whether it's safe to do non-blocking reads or writes from
inside the process callback.
From what I've seen, non-blocking I/O doesn't cause the process to go
into blocked state, and the realtime scheduler should not switch to
another process. But the documentation doesn't seem to allow them:
On which platform? [...] it cannot call functions that might block
for a long time. This
includes all I/O functions (disk, TTY, network), [...]
So, is it safe to use non-blocking I/O in the process callback?
The short answer is:
"If you don’t know how long it will take, don't do it." [1]
All i/o involve syscalls, and then it depends what the kernel does for
the specific system call(s). Asynchronous I/O usually involves signals
at some point which makes it not safe to use.
I wasn't very specific, let me clarify: I'm only going to do some
read(2) or write(2) syscalls on an FD which has O_NONBLOCK set.
AFAIK these don't involve signals... Some
implementation also
involve mutexes to avoid resource conflicts. You'll have to check the
standard-lib and kernel source for the system that you target.
Hmm... Are mutexes a problem if the FD is used exclusively from the
process callback? All moot
anyway. Proper software needs to do error-handling and doing
that in a rt-callback is out of the question. So you need a non-realtime
thread anyway and if you have that you can directly do i/o there.
Error handling is not a problem here, if those syscalls fail I'll simply
deactivate the JACK client.
anyway, using a ringbuffer to decouple i/o is
trivial: e.g.
https://github.com/jackaudio/example-clients/blob/master/capture_client.c
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. Thank you for your help,
Xavi
> best,
> robin
>
>
> [1]
>
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-…
>
>
7: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.
8:01 a.m.
El 30/11/15 a les 16:26, Paul Davis ha escrit:
Ok, all clear now. I'll use another worker thread, perform blocking I/O
and write to a ringbuffer.
On Mon, Nov 30, 2015 at 9:30 AM, Robin Gareus <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.
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. Keep jack freewheeling in mind. When freewheeling the
process callback
needs to wait for i/o to complete.
Good point.
7:36 a.m.
On Mon, Nov 30, 2015 at 12:11 PM, Xavier Mendez <me(a)jmendeth.com> wrote:
Hello,
I'm wondering whether it's safe to do non-blocking reads or writes from
inside the process callback.
From what I've seen, non-blocking I/O doesn't cause the process to go into
blocked state, and the realtime scheduler should not switch to another
process. But the documentation doesn't seem to allow them:
[...] it cannot call functions that might block for a long time. This
Depends what you mean by safe. Unless you require quite low latency, for
instance less than 256 frames, and if your program is not supposed to run
simultaneously with hard realtime software such as ardour, calling I/O
functions in the jack thread should work fine. But you need to inform your
users that the program should not run simultaneously with hard realtime
software.
includes all I/O functions (disk, TTY, network),
[...]
So, is it safe to use non-blocking I/O in the process callback?
3162
days inactive
3162
days old
jackaudio@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
Harry van Haaren -
Kjetil Matheussen -
Paul Davis -
Robin Gareus -
Xavier Mendez