[2/3 solved] CFMessage woe - was: CFNotificationCenter ./. NSNotificationCenter
[2/3 solved] CFMessage woe - was: CFNotificationCenter ./. NSNotificationCenter
- Subject: [2/3 solved] CFMessage woe - was: CFNotificationCenter ./. NSNotificationCenter
- From: email@hidden (Hado Hein)
- Date: Tue, 2 Mar 2010 02:16:50 +0100
- Organization: handmade !
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.
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden