[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:

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:


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