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

[Philippe Hausler]

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> wrote:
> 
> 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.
> > 
> 

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