Re: static acting like __block in GCD singleton pattern
Re: static acting like __block in GCD singleton pattern
- Subject: Re: static acting like __block in GCD singleton pattern
- From: Kyle Sluder <email@hidden>
- Date: Sat, 29 Jun 2013 09:53:45 -0700
On Sat, Jun 29, 2013, at 09:20 AM, Matt Neuburg wrote:
> I take it that the distinction we're drawing here is between static
> storage (which happens at file level and is therefore permanent)
Nitpick: static _storage_ doesn't have anything to do with the _file_.
The `static` keyword applied to a variable declaration at the top level
of a file does two things: it gives the variable static storage duration
(initialized to 0 at the start of the program, and living for the
duration of the program) _and_ it gives the variable file scope.
> automatic storage (which is limited to a scope, and dies when the scope
> dies). But I'm not clear on *why* that makes the difference. I guess it's
> because an automatic variable might die before the block can ever
> execute, but a static variable won't.
Yes. In order to make it possible to capture local variables in a block,
they are potentially hoisted to a storage that has the same lifetime as
the block. For readonly accesses, that doesn't matter; the value of the
expression is captured into the block context at the time of block
execution.
The issue is when the block is attempting to write back to the calling
environment. There's no guarantee that the write will happen while in
the same execution environment; the block might be copied to the heap
and executed later by a delay-perform. So the variable being written to
must _also_ have a lifetime that is at least as long as the block that
captures it. Thus, the `__block` storage class: a variable with __block
storage can actually move at runtime. Applying the address-of operator
to a `__block` variable twice in succession might yield different
results. The blocks spec requires you to acknowledge this radical
difference in behavior from other storage classes by spelling out
`__block` yourself.
> But then I'm still a little
> confused about which value of a static the block will use, the value at
> the time of definition or the value at the time of execution.
The word "definition" seems out of place here, because the definition of
a block happens at compile time.
The two actual possibilities are 1) at the time the block context is
constructed; and 2) at the time the block's invoke function pointer is
dereferenced and called. If you apply your existing knowledge of C
programming, it's easy to see that there's really no difference between
a block invocation and calling a function, so there's no reason to
assume the value of the static variable would be captured at context
construction time.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden