[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sc-dev] Patches for scsynth to communicate using mach messages
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:
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? 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?
Does anybody know if there's an API to browse for named mach ports? I
suppose rendezvous could be used for that as well.