[2/3 solved] CFMessage woe - was: CFNotificationCenter ./. NSNotificationCenter
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:
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. Basically I have several CFPlugIns (only linked against CF) that are supposed to run on headless servers; servicing some vendor specific usb device (and their plug/unplug notes in a secondary thread/runloop). These PlugIns maintain a CFMutableArray of CFDataRefs as table of contents. In the allocating code I'm doing the following: 1) iu_* me = (iu_ *) malloc(sizeof(iu_)); bzero( me, sizeof(iu_) ); 2) CFDataRef ptr = CFDataCreateWithBytesNoCopy ( NULL, me, sizeof(iu_), kCFAllocatorNull); 3) CFDictionarySetValue(me->infodict, idk_storage, ptr ); // the dict is deep copied mutable from a propertylist that is read from xml, I assume default callbacks 4) CFArrayAppendValue( ::arry, me ); // without default callbacks 5) printf("%p : Add instance to instacelist (from RC)\t\tcfdata %p intf %p\n", me, ptr, me); 6) CFDataRef tempdata = 0; 7) SInt32 result = CFMessagePortSendRequest( remoteMsgPort, kAddMessage, ptr, 1, 1, NULL, &tempdata); 8) //CFRelease(ptr); // leaving it out at the moment, so there is one retain at least Adding "ptr" to the dictionary works fine, also storing the natural data in the array. This part of the code runs reliable. Then I receive the message in 'messageCallBack ( CFMessagePortRef local, SInt32 msgid, CFDataRef data, void *info )' of the host app. *info isn't used at all. 1) CFMutableArrayRef list = getInstancelist(); // this is ok, I can dump the array in the debugger, it has default callbacks installed 2) publ_* iface = (publ_*)CFDataGetBytePtr(data); // this brings back a different CFDataRef than I've put in // anyhow, it's valid (as I can see through accessing the storage)... 3) printf("_ADD_ CALLBACK %@, cfdata %p, intf %p\n", stringID, data, iface); 4) CFArrayAppendValue( list, data); This logs like this: _ADD_ CALLBACK plugTX00ba, cfdata 0x3ab800, intf 0x1835e24 // wrong cfdataref, wrong interface // but the string 'plugTX00ba' is the correct value for the cfdata I've put in 0x1835e00 : Add instance to instacelist (from RC) cfdata 0x3989a0 intf 0x1835e00 // intf and cfdata are different in Message sender and a second instance _ADD_ CALLBACK plugRCee00, cfdata 0x35d530, intf 0x1838224 0x182e200 : Add instance to instacelist (from TX) cfdata 0x35aeb0 intf 0x182e200 // TX is doing the same in storing and sending Even if the CFMessagePortSendRequest line is after the printf line the logprints appear in reverse order. This happens at other places too, so I assume it not being important. In some intervals I log the Table of Devices, this shows me finally that the message sender still works ok. -- dump iu_[0x1835e00] -- dump iu_[0x182e200] dump of 'list'-Array in receiver instead: <CFArray 0x310050 [0xa080b1c0]>{type = mutable-small, count = 2, values = ( 0 : <CFData 0x3ab800 [0xa080b1c0]>{length = 1912, capacity = 1912, bytes = 0x00000000000000000000000000000000 ... d3c1b1a1d3c1b1a1} 1 : <CFData 0x35d530 [0xa080b1c0]>{length = 1912, capacity = 1912, bytes = 0x00440065007500740073006300680000 ... 0000000000000000} )} with the wrong CFDataRefs stored correct. ? thx, Hado. -- Hado Hein (KSK, DTHG), master craftsman of stagecrafts, 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
participants (1)
-
maclists@batchmaker.de