Realtime threads with Swift

[tera]

@carlos42421

So if someone is writing something like...

for n in 0...myArray.count {
  // do some hardware checking
  myArray[n].wasChecked = true
}

...then it can be unpredictable, I think. If myArray is a local array, not aliased, the memory is probably pretty straightforward, this is probably a single write to memory in a single location. If myArray is passed in as a parameter to a function that does this, but the function is inlined, then it might be basically the same. But if myArray is in a function and sometimes causes a C.O.W. then there could be a very large difference in execution time.
...
*This is just my opinion and just one case of realtime. If you're writing linux device drivers, or audio, or writing OpenGL pipeline then you'd probably have a different view from me!

dynamic structures like swift's array / dictionary / set are outlawed in real time safe code as they have internal reference types which could take locks (and cause memory allocation sometimes). taking a lock can take an unbounded amount of time, and real time code's main concern is hard limit on the time in the worst case scenario. (by the same logic if realtime code uses quicksort on arbitrary data it must assume its worst case O(n^2) performance, or switch to a true O(log(n)) worst case performance algorithm. swift "POD" structs only consisting of other POD structs and simple fixed types like bool / int / double / etc (but not dynamic types like string, data / url / etc) are realtime safe, and in swift we don't have the equivalent of C arrays, any algorithm that needs arrays would have to emulate them somehow (e.g. using preallocated memory + memmove).