Re: [2/3 solved] CFMessage woe
Re: [2/3 solved] CFMessage woe
- Subject: Re: [2/3 solved] CFMessage woe
- From: email@hidden (Hado Hein)
- Date: Thu, 4 Mar 2010 12:28:53 +0100
- Organization: handmade !
Iceberg-Dev <email@hidden> wrote:
> On Mar 2, 2010, at 2:16 AM, Hado Hein wrote:
>
> > Iceberg-Dev <email@hidden> wrote:
> >
> >> To communicate between 2 threads, you can use Message Port for
> >> instance, they work reliably.
> >
> > Thanks,
> > I heard your warnings and moved my code to use CFMessage APIs. They're
> > doing what I want - and that works. Unfortunately I feel a bit lost
> > with
> > one special part of the implementation of the neccessary callbacks for
> > the listening port.
> >
> >
> > I get correct data with wrong CFTypeRefs in my Callback; perhaps
> > one can
> > shed some mileage one this.
>
> It's not the same CFDataRef because:
>
> 1) the communication process is not local to the application.
>
> 2) CFMessagePort relies on Mach port which has no idea what a
> CFDataRef is. It's only the CFMessagePort wrapping around Mach port
> which is aware of the CFDataRef "struct".
Yes, but as far as I can't use the CFRef I got, I'd consider it a bug.
Or, since the CFMessage has beeen around long enough, I'd consider it
simply not working for me.
Restated.
In some creating code I do exact the following:
1) CFDataRef ptr = CFDataCreateWithBytesNoCopy ( NULL, me, sizeof(iu_),
kCFAllocatorNull);
2) CFDictionarySetValue(me->infodict, idk_storage, ptr );
3) CFDataRef tempdata = 0;
4) SInt32 result = CFMessagePortSendRequest( remoteMsgPort, kAddMessage,
ptr, 1, 1, NULL, &tempdata);
When my Callback is called I get a different CFDataRef that also gives
me a different ptr to the storage than I've created the object. (data is
the callback parameter).
1) publ_* iface = (publ_*)CFDataGetBytePtr(data);
2) CFDataRef tempPtr = CFDictionaryGetValue(iface->infodict, idk_storage
);
4) printf("-- %@ data %p intf %p dictcfdata %p dictptr %p\n",
iface->StringID, data, iface, tempPtr, CFDataGetBytePtr(tempPtr));
5) CFArrayAppendValue( list, tempPtr);
At the moment I'm simply using 'the other'(tm) way to get the backing
storage from the dict entry.
Which results always in this logprint:
...data 0xda47420 intf 0x1863a24 dictcfdata 0x395c70 dictptr 0x1851e00
Using this 'data' is valid for this one single call but I can't retain
that since it
a) makes other code that uses 'list' crash (regardless of the default
allocators on the Array or additional retains)
b) it's backing storage pointer isn't what I've put in.
I don't mind using the value from the dictionary, which I can access in
the callback to get my real data ptr - but it leaves a bad feeling of
knowing that at some other point, where I do not have a second value
available, I'd have to avoid messages.
--
Hado Hein (KSK, DTHG), Berlin
sip +49.30.91688488
www.beleuchtungsbildner.de - Stage Lighting Directing
www.batchmaker.de - Stage Lighting Design, Control and Routing
_______________________________________________
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