Re: Interprocess Communication (IPC) : Which "technology" to use?
Re: Interprocess Communication (IPC) : Which "technology" to use?
- Subject: Re: Interprocess Communication (IPC) : Which "technology" to use?
- From: Jerry Krinock <email@hidden>
- Date: Tue, 7 Dec 2010 12:44:50 -0800
Thank you. I found an example of shared memory segments here:
http://software.itags.org/software-mac-os/235083/
(Looks like the original server of this page is down.)
And an example of CFMessagePort here:
http://www.omnigroup.com/mailman/archive/macosx-dev/2001-June/028795.html
Given what I know, the CFMessagePort looks like a faster solution for me. Very lean and just what you'd expect. The server names the port and defines a callback which returns a response. The client names the same port when sending a request and the response is returned by reference. I updated Douglas Davidsons' year-2001 code given in there, to remove compiler warnings.
So it looks like I get to go another year without tackling Distributed Objects. Whew!
To view the demo, compile and run the Server, then compile and run the Client.
/*** CFMessagePortDemoServer.c ***/
#include <CoreFoundation/CoreFoundation.h>
CFStringRef kPortName = CFSTR("MyCFMessagePortDemo") ;
CFDataRef myCallBack(
CFMessagePortRef local,
SInt32 msgid,
CFDataRef data,
void *info) {
char *message = "I'm at your service!";
UInt8 *bytes = (UInt8*)message ;
int dataLength = strlen(message) + 1;
CFDataRef returnData = CFDataCreate(
NULL,
bytes,
dataLength);
printf(
"Received data from a client: %s\n",
CFDataGetBytePtr(data));
// From CFMessagePortCallBack documentation, we return the
// "data to send back to the sender of the message. The system
// releases the returned CFData object."
return returnData;
}
int main() {
CFMessagePortRef local = CFMessagePortCreateLocal(
NULL,
kPortName,
myCallBack,
NULL,
false);
CFRunLoopSourceRef source = CFMessagePortCreateRunLoopSource(
NULL,
local,
0);
CFRunLoopAddSource(
CFRunLoopGetCurrent(),
source,
kCFRunLoopDefaultMode);
// The following will block as long as message port is still valid
// and source remains on the run loop
CFRunLoopRun();
CFRelease(local);
}
Also, quoting from Douglas' original comments,
"As for using it within a Cocoa run loop--by which I assume you mean the main run loop in an AppKit-based application--that is even easier. In that case, the server doesn't run the run loop itself, it just adds the source to the current run loop and lets the AppKit run it…"
/*** CFMessagePortDemoClient.c ***/
#include <CoreFoundation/CoreFoundation.h>
CFStringRef kPortName = CFSTR("MyCFMessagePortDemo") ;
int main() {
CFMessagePortRef remote = CFMessagePortCreateRemote(
NULL,
kPortName
);
char *message = "Hello, I'm a client!";
UInt8 *bytes = (UInt8*)message ;
int dataLength = strlen(message) + 1;
CFDataRef data, returnData = NULL;
data = CFDataCreate(NULL,
bytes,
dataLength);
SInt32 result = CFMessagePortSendRequest(remote,
0,
data,
1,
1,
kCFRunLoopDefaultMode,
&returnData) ;
if (
(result == kCFMessagePortSuccess)
&&
(returnData != NULL)
) {
printf(
"Received data from the server: %s\n",
CFDataGetBytePtr(returnData));
CFRelease(returnData);
}
CFRelease(data);
CFRelease(remote);
}
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden