<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div>As a note: our closure implementation in Foundation does NOT adhere to this (since it would mean that we would need to alter the c compiler to do so and that was not something that I have gotten to look at beyond a cursory glance.</div><div><br class=""></div><div>So the change would be effectively something like this:</div><div><br class=""></div><div>struct Block_layout {<br class=""> void *isa;<br class="">#if DEPLOYMENT_RUNTIME_SWIFT<br class=""> uint32_t refCount;<br class=""> uint32_t weakRefCount;<br class="">#else // not certain this branch can happen or not. we may need both</div><div> volatile int32_t flags; // contains ref count<br class=""> int32_t reserved;</div><div>#endif</div><div> void (*invoke)(void *, ...);<br class=""> struct Block_descriptor_1 *descriptor;<br class=""> // imported variables<br class="">};</div><div><br class=""></div><div>and making the retain and release methods for blocks just call swift_retain and swift_release. But since blocks may be emitted by the compiler we would need to make certain that the compiler had a flag to emit those with the new layout and emit correct values for the refCount fields to give it immortality for things like global static blocks etc.</div><div><br class=""></div><div>Then we would need to find some way to have the values for:</div><div><br class=""></div><div>void * _NSConcreteStackBlock[32] = { 0 };<br class="">void * _NSConcreteMallocBlock[32] = { 0 };<br class="">void * _NSConcreteAutoBlock[32] = { 0 };<br class="">void * _NSConcreteFinalizingBlock[32] = { 0 };<br class="">void * _NSConcreteGlobalBlock[32] = { 0 };<br class="">void * _NSConcreteWeakBlockVariable[32] = { 0 };</div><div><br class=""></div><div>these guys emitted as objects as well so that the isa’s would be treated correctly.</div><div><br class=""></div><div>I am not certain on how much of this lofty goal is actually needed; perhaps we should loop in one of the compiler team in on this to query what really needs to be done to properly support the @convention(block) syntax on linux. Perhaps I am overthinking this.</div></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 14, 2016, at 2:49 PM, David P Grove <<a href="mailto:groved@us.ibm.com" class="">groved@us.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><p class=""><tt class=""><a href="mailto:phausler@apple.com" class="">phausler@apple.com</a> wrote on 01/13/2016 06:04:23 PM:</tt><br class=""><tt class="">> <br class="">> Tony brought up an important point about the prep for integration <br class="">> this morning: the blocks runtime from libblocksruntime-dev will be <br class="">> incompatible with the layout of blocks referenced from swift since <br class="">> the object size there is 2 uint32’s bigger to handle the RR (we <br class="">> don’t have objc). Without modifying clang and the runtime we won’t <br class="">> have a way to properly handoff blocks back and forth w/o objc.</tt><br class=""><br class=""><tt class="">Hi,</tt><br class=""><br class=""><tt class=""> I'm guessing RR expands to Retain Release?</tt><br class=""><br class=""><tt class=""> I've started exploring the source in swift-corelibs-foundation/closure. Any chance there is a design doc laying out the object model used by the Swift implementation? I'm sure I could figure it out from the source code, but it would be nice to be able to cheat and start with a an overview.</tt><br class=""><br class=""><tt class="">thanks,</tt><br class=""><br class=""><tt class="">--dave</tt><br class=""><br class=""><tt class="">> <br class="">> I am currently taking a look at this to see what we can do to add an<br class="">> option to the clang code-gen to properly emit this structural <br class="">> difference. This isn’t a big issue for Foundation to CF since we <br class="">> don’t have many block APIs but dispatch is mostly blocks and that <br class="">> might pose an issue.</tt><br class=""><tt class="">> <br class=""></tt><br class="">
</p></div>
</div></blockquote></div><br class=""></body></html>