- 主题:C++有什么好用的进程内 + 进程间通信框架？
1、至少支持进程内的。烦了“线程间直接加锁然后互相call来call去的”这种模式了。类似Rust那种SPSC、MPSC的，或者进程内消息队列也行。
chrome的？
2、能同时也支持同一台机器的进程间最好，不支持也行。不需要跨机器。
3、win/linux/macos的客户端平台。
3Q
--
修改:z16166 FROM 114.241.227.*
FROM 114.241.227.*
进程内的，boost aiso post lamda，我觉得很好用，不用操心消息序列化啥的，lamda直接捕获然后post lamda到对方的io context执行
【 在 z16166 的大作中提到: 】
: 1、至少支持进程内的。烦了“线程间直接加锁然后互相call来call去的”这种模式了。类似Rust那种SPSC、MPSC的，或者进程内消息队列也行。
: chrome的？
: 2、能同时也支持同一台机器的进程间最好，不支持也行。不需要跨机器。
: ...................
--
FROM 123.168.94.*
进程内消息队列不是很简单么。。自己仿 java 写个 blocking queue 就行了，类似这样的：
https://github.com/hgoldfish/qtblockingqueue
重一点或许可以上 ZeroMQ
【 在 z16166 的大作中提到: 】
: 1、至少支持进程内的。烦了“线程间直接加锁然后互相call来call去的”这种模式了。类似Rust那种SPSC、MPSC的，或者进程内消息队列也行。
: chrome的？
: 2、能同时也支持同一台机器的进程间最好，不支持也行。不需要跨机器。
: ...................
--
修改:hgoldfish FROM 120.33.9.*
FROM 120.33.9.*
Unix Network Programming vol2
记得里面谈到过 message queue 的用法，虽然那部分我没细读过。
【 在 z16166 的大作中提到: 】
: 1、至少支持进程内的。烦了“线程间直接加锁然后互相call来call去的”这种模式了。类似Rust那种SPSC、MPSC的，或者进程内消息队列也行。
: chrome的？
: 2、能同时也支持同一台机器的进程间最好，不支持也行。不需要跨机器。
: ...................
--
FROM 216.240.30.*
zeromq
【 在 z16166 的大作中提到: 】
: 1、至少支持进程内的。烦了“线程间直接加锁然后互相call来call去的”这种模式了。类似Rust那种SPSC、MPSC的，或者进程内消息队列也行。
: chrome的？
: 2、能同时也支持同一台机器的进程间最好，不支持也行。不需要跨机器。
: ...................
--
FROM 221.219.211.*
不嫌麻烦可以自己写
核心就是个ringbuf，放在普通内存里就是进程内通讯，放到共享内存里就是进程间通讯
外边套上一堆用atomics和intrinsics弄出来的状态管理
嫌麻烦可以去GitHub上找找，很多，良莠不齐，以lmax disruptor为代表
复古可以用zmq或nanomsg，还有各种基于socket开发的网络库
Windows和unix上还有操作系统支持的各种进程间通讯机制
【 在 z16166 的大作中提到: 】
: 1、至少支持进程内的。烦了“线程间直接加锁然后互相call来call去的”这种模式了。类似Rust那种SPSC、MPSC的，或者进程内消息队列也行。
: chrome的？
: 2、能同时也支持同一台机器的进程间最好，不支持也行。不需要跨机器。
: ...................
--
FROM 123.112.17.*
进程内消息队列（消息循环）我一般把它分两种：
- IO类，主循环是epoll/select，处理IO事件。典型的例子是Glib的mainloop
- 自定义消息类，主循环处理自定义消息，一般在等待一个condition variable；以上层逻辑为主。典型的例子是WinMain、安卓应用的主线程的HanlerLooper
这两种消息循环都可以往里面扔lambda或者std::function形式的回调函数，往IO类里扔的时候一般会封一个timerfd支持延迟回调或立即回调两种。
还有一种设计思想，是把这两种消息循环统一成epoll，那就要把condition variable变成文件描述符，可以用考虑用eventfd。不过我还是更倾向于各干各的。
跨进程的，比如binder或DBus或socket，在进程内部就是一个IO类消息循环，拿到数据后丢消息到自定义消息循环。
具体实现的话，chrome里有MessageLoopForUI/MessageLoopForIO/MessageLoop可以参考。可以按照需求做些修改
【 在 z16166 的大作中提到: 】
: 1、至少支持进程内的。烦了“线程间直接加锁然后互相call来call去的”这种模式了。类似Rust那种SPSC、MPSC的，或者进程内消息队列也行。
: chrome的？
: 2、能同时也支持同一台机器的进程间最好，不支持也行。不需要跨机器。
: ...................
--
FROM 111.198.228.*
这个问题拔高一个层次看，是一个设计模式问题；
你说的线程之间加锁来回调用，是典型的同步设计方法，优点是业务逻辑容易理解，新手易上手；
缺点是它把执行环境和业务逻辑绑定了，一个线程就等固定的事件、干固定的活。
消息队列方式，是异步的，特别容易支持订阅发布这种模式；缺点是系统大了不那么容易理解、上手。
如果整个系统都是单向发布消息还好，如某些消息是双向的、还需要接受者发结果回来，那这结果可以走一条消息回来，也可以是在参数消息里加一个callback，通过callback处理结果。
这样的系统一旦复杂了，调查问题只能通过看日志去理解它的整个运作过程。
用同步或异步的设计方法，最大的障碍是团队内部成员是否都理解、接受这种变革或重构。
【 在 AudiDoggie 的大作中提到: 】
: 进程内消息队列（消息循环）我一般把它分两种：
: - IO类，主循环是epoll/select，处理IO事件。典型的例子是Glib的mainloop
: - 自定义消息类，主循环处理自定义消息，一般在等待一个condition variable；以上层逻辑为主。典型的例子是WinMain、安卓应用的主线程的HanlerLooper
: ...................
--
FROM 111.198.228.*
说下应用场景，一般化的框架虽然用起来方便，但是性能肯定是受影响的
【 在 z16166 的大作中提到: 】
: 1、至少支持进程内的。烦了“线程间直接加锁然后互相call来call去的”这种模式了。类似Rust那种SPSC、MPSC的，或者进程内消息队列也行。
: chrome的？
: 2、能同时也支持同一台机器的进程间最好，不支持也行。不需要跨机器。
: ...................
--
FROM 122.234.150.*