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

[Xavier Mendez]

El 30/11/15 a les 14:27, Robin Gareus ha escrit:
> 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:
>>
>>> [...] 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?
>>
>
> On which platform?

This is going to run on UNIX-like systems, mostly Linux, and I'm 
programming in C/C++.

> 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-for-nothing
>