[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] Patches for scsynth to communicate using mach messages
On Nov 27, 2004, at 3:25 PM, Patrick Beard wrote:
I've been wondering if there's any interest in communicating with the
scsynth process using mach messages rather than UDP/TCP through the
loopback interface. In theory, this could be faster than going through
the TCP stack. I've submitted a patch to the SuperCollider project on
source forge here:
Hi Patrick. Seems like a useful optimization. I'll have a look.
My current approach is to use CFMessagePort, for ease of
implementation, but it may prove more efficient to move to the lower
level mach_msg() call documented here:
at least in the server.
I've also modified the CocoaSC class to have two private sublasses of
OSCPort one of which communicates over TCP, and the other over
One interesting issue is how get replies. The new class I added in
SC_ComPort.h, SC_MachMessagePort, opens a local CFMessagePort to
receive messages, and a remote CFMessagePort to send replies to. I did
it this way, because I didn't see any easy way to block the port
thread until a reply is ready, and return a reply from the
messagePortCallBack() function. Is there a way to tell what requests
will generate replies, and only block in those cases?
If the message were an OSC bundle then it might contain several
messages that get replies.
The main benefit to blocking before returning is that replies are
automatically directed to the sender, and there can then be multiple
clients. The downside is that it stops being asynchronous, so perhaps
my approach of using two ports is the best way to go.
What would be the best way to measure the difference in latency of
using mach messages vs. IP?
The server needs a ping command that stores times.
Does anybody know if there's an API to browse for named mach ports? I
suppose rendezvous could be used for that as well.