[swift-corelibs-dev] libdispatch prep for integration to the rest of swift-corelibs

[Pierre Habouzit]

well dispatch also uses a bit of the blocks runtime because it uncorks the blocks and gets to the captured function pointer.

This is used pervasively, through this macro (internal.h):

#define _dispatch_Block_invoke(bb) \
		((dispatch_function_t)((struct Block_layout *)bb)->invoke)

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).

technically speaking dispatch only cares about the offsets/sizes and not about the rest of the layout.

-Pierre

> On Jan 14, 2016, at 3:00 PM, Philippe Hausler via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> 
> 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.
> 
> So the change would be effectively something like this:
> 
> struct Block_layout {
>     void *isa;
> #if DEPLOYMENT_RUNTIME_SWIFT
>     uint32_t refCount;
>     uint32_t weakRefCount;
> #else // not certain this branch can happen or not. we may need both
>     volatile int32_t flags; // contains ref count
>     int32_t reserved;
> #endif
>     void (*invoke)(void *, ...);
>     struct Block_descriptor_1 *descriptor;
>     // imported variables
> };
> 
> 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.
> 
> Then we would need to find some way to have the values for:
> 
> void * _NSConcreteStackBlock[32] = { 0 };
> void * _NSConcreteMallocBlock[32] = { 0 };
> void * _NSConcreteAutoBlock[32] = { 0 };
> void * _NSConcreteFinalizingBlock[32] = { 0 };
> void * _NSConcreteGlobalBlock[32] = { 0 };
> void * _NSConcreteWeakBlockVariable[32] = { 0 };
> 
> these guys emitted as objects as well so that the isa’s would be treated correctly.
> 
> 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.
> 
>> On Jan 14, 2016, at 2:49 PM, David P Grove <groved at us.ibm.com <mailto:groved at us.ibm.com>> wrote:
>> 
>> phausler at apple.com <mailto:phausler at apple.com> wrote on 01/13/2016 06:04:23 PM:
>> > 
>> > Tony brought up an important point about the prep for integration 
>> > this morning: the blocks runtime from libblocksruntime-dev will be 
>> > incompatible with the layout of blocks referenced from swift since 
>> > the object size there is 2 uint32’s bigger to handle the RR (we 
>> > don’t have objc). Without modifying clang and the runtime we won’t 
>> > have a way to properly handoff blocks back and forth w/o objc.
>> 
>> Hi,
>> 
>> I'm guessing RR expands to Retain Release?
>> 
>> 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.
>> 
>> thanks,
>> 
>> --dave
>> 
>> > 
>> > I am currently taking a look at this to see what we can do to add an
>> > option to the clang code-gen to properly emit this structural 
>> > difference. This isn’t a big issue for Foundation to CF since we 
>> > don’t have many block APIs but dispatch is mostly blocks and that 
>> > might pose an issue.
>> > 
>> 
> 
> 
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160114/904809ae/attachment.html>