[ASDisplayNode] Implement recursivelyDetachedFromMainThread to indicate thread affinity state of subtrees.

[zintus]

I've approached this problem as discussed in #927.

New property used in data controller to ensure that faced hierarchy of nodes is available to measure on background thread. Effectively recursivelyDetachedFromMainThread is opposite of isNodeLoaded calculated over hierarchy, but it never becomes detached again after node unloaded, following comment on view and layer properties.

[appleguy]

@zintus thanks for working on this! It's an interesting improvement. I will need to think a bit more about this because I am also working in this area, and might be going a slightly different direction. However it is definitely true that right now it is possible to have loaded a subnode of a cell node, and then trigger an assertion on layout when the cell node tries to measure off the main thread (because the cell itself isn't loaded). This improvement would fix that and enable a few other improvements.

In the not too distant future, @Adlai-Holler and I plan to completely rewrite the ASDK thread affinity system to actually remove the requirement to use only on the main thread after they are loaded. That's a primary reason I'm wondering if this is the right direction...

[zintus]

No problem, I'm completely ok with holding this feature until new threading
model arrives 🌞
On Thu, 24 Dec 2015 at 04:13, appleguy notifications@github.com wrote:

@zintus https://github.com/zintus thanks for working on this! It's an
interesting improvement. I will need to think a bit more about this because
I am also working in this area, and might be going a slightly different
direction. However it is definitely true that right now it is possible to
have loaded a subnode of a cell node, and then trigger an assertion on
layout when the cell node tries to measure off the main thread (because the
cell itself isn't loaded). This improvement would fix that and enable a few
other improvements.

In the not too distant future, @Adlai-Holler
https://github.com/Adlai-Holler and I plan to completely rewrite the
ASDK thread affinity system to actually remove the requirement to use only
on the main thread after they are loaded. That's a primary reason I'm
wondering if this is the right direction...

—
Reply to this email directly or view it on GitHub
#977 (comment)
.

[appleguy]

@zintus thank goodness, the new threading model has been landed for a while now and has proven to be quite stable even with extensive usage!

Although I am not certain if this is 100% supported yet, in the very very near future it should be possible to have even loaded no it hierarchies be measured off the main thread by ASDataController. In fact, we are using this capability in Pinterest - asynchronous measurement of loaded node hierarchies, with an animated transition being triggered at the moment that the measurement completes. This system has been constructed with thread safety front and center, so that even a call to -setNeedsLayout in the middle of the asynchronous measurement phase or the transition itself is handled consistently.

That support is relatively new, although also enjoying widespread use in a very stressful use case at Pinterest (multiple calls to -transition potentially before the prior finishes, due to various updates coming in to the underlying app / server data model). The one part that I am not as certain of is, if the transition API is not use directly as is the case for the data controller, can we remove the support for main thread layout of loaded nodes?

@nguyenhuy wouldn't know the answer to this question, and although it Would take us at least a couple weeks to investigate, I think that will be the ultimate fix here...rather than supporting more easily creating dual-path code intending to support the previous, rather frustrating threading model.

Just as a quick note, it is still not thread safe to read properties that are bridged to the system objects off of the main thread, after the backing system objects are created. There is no plan to support this in the near future, although it might be possible with further sophistication in the pending state... The reason is that in my many years of using this framework, I have found that it is always quite easy to avoid relying on this capability. Paper had a write-from-background threading model supported in its version of the framework, but I was always able to ensure that Reading from the background was avoided by providing other facilities (e.g. instead of self.bounds, look at constrainedSize).

[appleguy]

Please feel free to open an Issue or email me at asyncdisplaykit@gmail.com, any time, even just with some comments about how you have used the framework or what it could do better - I would love to hear it!