[sc-dev] Patches for scsynth to communicate using mach messages

[Patrick Beard <pcbeard@xxxxxxx>]

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:

https://sourceforge.net/tracker/index.php? 
func=detail&aid=1074372&group_id=54622&atid=474250

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:

http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/mach_msg.html

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  
CFMessagePort.

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.

- Patrick