mikeash.com pyblog/friday-qa-2017-09-22-swift-4-weak-references.html comments

mikeash - 2017-10-28 15:06:39

Sat, 28 Oct 2017 15:06:39 GMT

Michael M. Mayer: Thanks for the reminder. I'll see if I can do that topic soon.

Michael M. Mayer - 2017-10-21 19:51:44

Sat, 21 Oct 2017 19:51:44 GMT

You mentioned on Swift Unwrapped that you were considering doing unowned references as a follow up to this article (which was your usual wonderful). That would be great if you could explain unowned references under Swift 4. Thanks!

Evan Olcott - 2017-09-24 09:54:16

Sun, 24 Sep 2017 09:54:16 GMT

Well then, that begs the question (sorta): is the an equivalent locking, dynamic, “function cache”?

mikeash - 2017-09-23 23:40:43

Sat, 23 Sep 2017 23:40:43 GMT

K: Mostly from reading the source (including the excellent comments within) and some runtime inspection. There are things where looking at the bits and bytes is easier than decoding the C++. My memorydumper2 (https://github.com/mikeash/memorydumper2) project helped a lot, although it had some trouble due to the low bits used as flags. I have no idea where one might find design info besides the mailing lists.

Evan Olcott and Jean-Daniel: There are several ways for ObjC to go wrong in a real-time thread. Memory allocation is one, as mentioned. Another is the potentially unbounded search time for the target method if the method cache doesn't contain it (which can happen at any time due to other code clearing the cache). In rare cases you can end up trying to acquire locks, such as when you're sending the first message to a class (which could be a dynamically allocated subclass like the ones used with KVO).

Jean-Daniel - 2017-09-23 21:36:01

Sat, 23 Sep 2017 21:36:01 GMT

@Evan Olcott: I think that the main issue with Obj-C in real time thread is not the retain count side table, it is the method cache. Any call can require it to grow and doing so require an calloc call that is not safe on real-time thread.

Evan Olcott - 2017-09-23 20:20:33

Sat, 23 Sep 2017 20:20:33 GMT

This is the first time I’ve seen an honest explanation about why it’s said to “not use objective c for real-time threads because any objective c call can lock”. It’s reading from a shared table and hS to protect access.

So, that said, it appears as though native Swift does not have this problem? Is that true? Does Swift use any locking in object access? If not, that could open up a whole new world for real-time threads...

K - 2017-09-23 19:00:07

Sat, 23 Sep 2017 19:00:07 GMT

This is a nice, clear description of weakrefs in Swift.

Did you get this entirely from reading the source? If so, that's impressive. (Where do you find hours in the day?)

I assume that the folks on the Swift core team use whiteboards or something. Is there any way us mortals can get access to any higher-level design specifics? Swift-evo is neat but that seems to be more documentation after-the-fact.

Or do they actually hash all this out by emails that say "We should do X", "No, that doesn't take into account issue Y", "OK, so Z it is. I'll write the code now", etc?

I've written compilers before and I don't know how you can write a compiler without a few square miles of whiteboards.