Nice. You may want to change from Int32 to a bigger type or to UIn32, otherwise the buffer will overflow in a few hours and array index will go negative and crash. Also worth changing += to &+=.
I don't think that per se will fly: you need the same struct for reader and writer (which are in different threads), meaning it has to either be in a class or in a global variable. In both of these cases get/put will have retain/release if the underlying storage is left as swift array.
Very true.
That was the question I had at one point: what materially changed between WWDC 2015 and WWDC 2016 in this regard... I never found an authoritative answer.
I brought up realtime audio as an answer to "can I do everything in swift". The answer I was conveying "perhaps you could, just there are better tools for specific jobs".
A few things for your third bullet point:
- realtime programming peculiarity is that it's not about overall speed or average latency -- it's about worst case behaviour. Often times latency is sacrificed for speed. Speed can be much faster but if there is an extra lock (where there was no lock previously) or, say, if the worst case behaviour changed from O(N) to O(N²) (even if the average behaviour got improved from O(N) to O(log₂N) - that would be a problem for realtime code.
- Just recently we were discussing a speed regression reproduced in SwiftUI(Seven seconds to render SwiftUI - #33 by tera) observed on new macOS versions. Perhaps there was a good reason for this slowdown, just note: newer is not necessarily faster.
- "The compiler's internals can change at any time" - that's why the idea of
@realtimekeyword discussed in the other mentioned thread is so appealing, it would remove any guesswork or trial and error. With this keyword swift could become better than C IRT realtime programming.
You started to sound reasonable, good job.