What are those locks I see in realtime functions? Sources of unbounded runtime and hanged machines?
Can you prove they are always safe? (at least on the level of linux kernel LOCKDEP)
I bet you cannot, because 1.1.0 changelog mentions "fixing" a deadlock by tossing functionality.
Likewise, I see a lot of places that do reference counting (those _ref/_unref calls). Those are probable deallocations on heap from RT side, which have unbounded runtime unless you have a realtime memory allocator. I haven't noticed anything like that in the code.
This coming from a guy who supposedly "has carefully read the documentation for every audio backend and understands the purpose of every line of code."
For people who want to get a primer on such issues, I recommend this book: http://www.amazon.com/Real-Time-Systems-Programming-Language...
It's a bit old despite updates (e.g. no C++11, no C99), but still highly relevant. The techniques themselves and the analysis parts are well written.
Can you prove they are always safe? (at least on the level of linux kernel LOCKDEP) I bet you cannot, because 1.1.0 changelog mentions "fixing" a deadlock by tossing functionality.
Likewise, I see a lot of places that do reference counting (those _ref/_unref calls). Those are probable deallocations on heap from RT side, which have unbounded runtime unless you have a realtime memory allocator. I haven't noticed anything like that in the code.
This coming from a guy who supposedly "has carefully read the documentation for every audio backend and understands the purpose of every line of code."
For people who want to get a primer on such issues, I recommend this book: http://www.amazon.com/Real-Time-Systems-Programming-Language... It's a bit old despite updates (e.g. no C++11, no C99), but still highly relevant. The techniques themselves and the analysis parts are well written.