<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="">well dispatch also uses a bit of the blocks runtime because it uncorks the blocks and gets to the captured function pointer.<div class=""><br class=""></div><div class="">This is used pervasively, through this macro (internal.h):</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 10px; line-height: normal; color: rgb(210, 143, 90);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><font face="Menlo" class="">#define _dispatch_Block_invoke(bb) \</font></span></div><div style="margin: 0px; font-size: 10px; line-height: normal; color: rgb(210, 143, 90);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>((dispatch_function_t)((struct Block_layout *)bb)->invoke)</font></span></div></div><div class=""><br class=""></div><div class="">And we need to know the size of the Block_layout for a simple block (abused in _dispatch_block_get_data(), see inline_internal.h).</div><div class=""><br class=""></div><div class="">technically speaking dispatch only cares about the offsets/sizes and not about the rest of the layout.</div><div class=""><br class=""><div class="">
-Pierre
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Jan 14, 2016, at 3:00 PM, Philippe Hausler via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">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 class=""><br class=""></div><div class="">So the change would be effectively something like this:</div><div class=""><br class=""></div><div class="">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 class=""> volatile int32_t flags; // contains ref count<br class=""> int32_t reserved;</div><div class="">#endif</div><div class=""> void (*invoke)(void *, ...);<br class=""> struct Block_descriptor_1 *descriptor;<br class=""> // imported variables<br class="">};</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Then we would need to find some way to have the values for:</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">these guys emitted as objects as well so that the isa’s would be treated correctly.</div><div class=""><br class=""></div><div class="">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 class=""><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="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ST9LHNQ2kYRKURQJ7G-2FmGJ7cPtWGB-2BbbnqmgrSbiwvh2zUjMBvxZA4yJRaeYSv2NBRJ7uNCOoCbjqWhCSPFTpTfZmVXoH-2F86C0GXHGLmVEQtyhj4BOt6JPn3c3oxnQDd0cwvmvCiWax3F29do35zsWfvGcChy6lG1GR4Ehhnrvx7psi6dzodIFJnHMwXFqpt6r7B6xD8-2BjMpjjN3srmcxuTIrlK8ChlsPgGBX7wrJTE-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev<br class=""></div></blockquote></div><br class=""></div></body></html>