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 14:39:40 +0100
- Organization: handmade !
Dave Keck <email@hidden> wrote:
> You could of course wrap a pointer in a data object:
>
> Meanwhile, on the receiving end:
>
> And after receiving the message, receivedPointer == the original myPointer.
That is what I'm doing. Of course I do alloc my pointer.
See the resulting logprints source.
That behaviour is exactly what I want, assume, but don't get.
> Some other thoughts:
>
> 1. I'm having a hard time understanding exactly what you want to do;
> it'd help if you could explain from a high-level what your goal is.
> 2. Is there a reason you can't link Foundation? It will make your life
> much easier; you could send your pointer to another thread in a single
> line and avoid the CFMessage APIs altogether.
> 3. You would get a lot more useful feedback if this were on Cocoa dev. :)
Dave, first thanks for your notes.
In reverse I'd say
3) Why should I ask a pure CF problem on the Cocoa-List?
2) I don't want to. Anything that is not linked doesn't cost or change.
Otoh I really use my CFPlugIns with posix/commandline or Cocoa.
1) As I said in the OP: I'm having CFPlugIns for the purpose of using
them as such. Users probably will call them "Driver-Plugins".
Please don't confuse this as a Cocoa-Click-Click-Project.
The plugIns were first there and must run on CF(Lite).
That's why I've choosen CFPlugIns. They are reusable in several contexts
and present a uniform interface that others may implement.
This works reliable since a decade now.
Above my PlugIns the worlds envolved but the PlugIns hadn't to be
touched.
They were low enough to survive all changes in the OS above it.
Otoh when I do a new GUI App using them I usually choose Cocoa. That's
why there was Cocoa in my OP.
For pure distributed processing nodes I do commandline stuff.
Back to the problem as seen at the top of the message:
but what I don't need is a copy of my data; I don't mind a different
CFRef as long as it points to the raw storage that I've put in.
There is only one execution context (process + MainRunloop) with several
pthreads, some of them with RunLoops others pure posix.
In the CFPlugIn, that is loaded from some app (regardless of CommandLine
or Cocoa), is an alloc for storage. This wrapped into a CFDataRef which
then is sent out.
In the same process + addressSpace, in a different Runloop, I receive
this message, and the data is unusable for me.
This copy doesn't reflect later state changes of the device represented
by the raw storage.
E.g. the classic green LED for everthing is ok may change frequently.
This is stored by the devices usb communications handling in that
memory. On any output I'm polling that bool and decide if I sprintf
running or stalled.
Regardless of where (GUI, cmdline) I'm executed I have a list of my
IUnknown/myGreatPlugInInterface interfaces. So I can lazyly build status
strings from raw memory.
--
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