Re: Blocks
Re: Blocks
- Subject: Re: Blocks
- From: Jean-Daniel Dupas <email@hidden>
- Date: Mon, 16 Nov 2009 19:17:17 +0100
Le 16 nov. 2009 à 18:32, Damien Sorresso a écrit : On Nov 16, 2009, at 7:21 AM, Clark Cox wrote: On Mon, Nov 16, 2009 at 2:51 AM, Filip van der Meeren
<email@hidden> wrote:
Hi,
Sorry if I am posting this on the wrong forum. But I really do not know
where to post this message.
Is it possible to archive/store a block?
I do not believe so. Think about what that would entail; it would have
to save all of its code, as well as all of its context; and would have
to do so in a way that would remain valid across process launches
(what happens if someone archives a block in 32-bit code, but attempts
to call it from 64-bit code, etc.)
I imagine that this is where using llvm to generate intermediary byte-code would be helpful.
In reality, generating IR will not help. IR generated from C is not architecture independent. What if the block code contains an #ifdef __LP64__ ? But preserving context would be the tricky part. If a block captures a pointer, that address won't be valid when you unarchive the block. You'd have to store what that address points to, load it into memory at unarchiving time and then update the block's captured pointer accordingly.
So it gets really unwieldy when you start introducing things like CoreFoundation objects or Objective-C objects that don't comply with NSCoder. And it gets even worse if you're calling any API from within your block and assuming a certain state in the framework backing that API. The block has no idea what the framework's backing state is (maybe the framework needs to initialize a global, or certain things your program has done beforehand have changed that state from its initial value), so it can't capture that context and reinitialize.
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
References: | |
| >Blocks (From: Filip van der Meeren <email@hidden>) |
| >Re: Blocks (From: Clark Cox <email@hidden>) |
| >Re: Blocks (From: Damien Sorresso <email@hidden>) |