site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Organization: handmade ! User-agent: MacSOUP/D-2.7 (Mac OS X version 10.4.9) Iceberg-Dev <dev.iceberg@gmail.com> wrote:
On Mar 2, 2010, at 2:16 AM, Hado Hein wrote:
Iceberg-Dev <dev.iceberg@gmail.com> 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com