mutouyun / cpp-ipc Goto Github PK

View Code? Open in Web Editor NEW

1.7K 53.0 326.0 3.16 MB

C++ IPC Library: A high-performance inter-process communication using shared memory on Linux/Windows.

License: Other

C 12.62% C++ 85.23% CMake 2.15%

cpp cpp17 ipc shared-memory linux windows

cpp-ipc's Introduction

cpp-ipc (libipc) - C++ IPC Library

A high-performance inter-process communication library using shared memory on Linux/Windows.

Compilers with C++17 support are recommended (msvc-2017/gcc-7/clang-4)
No other dependencies except STL.
Only lock-free or lightweight spin-lock is used.
Circular array is used as the underline data structure.
ipc::route supports single read and multiple write. ipc::channel supports multiple read and write. (Note: currently, a channel supports up to 32 receivers, but there is no such a limit for the sender.)
Broadcasting is used by default, but user can choose any read/ write combinations.
No long time blind wait. (Semaphore will be used after a certain number of retries.)
Vcpkg way of installation is supported. E.g. vcpkg install cpp-ipc

Usage

See: Wiki

Performance

Environment	Value
Device	Lenovo ThinkPad T450
CPU	Intel® Core™ i5-4300U @ 2.5 GHz
RAM	16 GB
OS	Windows 7 Ultimate x64
Compiler	MSVC 2017 15.9.4

Unit & benchmark tests: test
Performance data: performance.xlsx

Reference

使用共享内存的跨平台（Linux/Windows，x86/x64/ARM）高性能IPC通讯库

推荐支持C++17的编译器（msvc-2017/gcc-7/clang-4）
除STL外，无其他依赖
无锁（lock-free）或轻量级spin-lock
底层数据结构为循环数组（circular array）
ipc::route支持单写多读，ipc::channel支持多写多读【注意：目前同一条通道最多支持32个receiver，sender无限制】
默认采用广播模式收发数据，支持用户任意选择读写方案
不会长时间忙等（重试一定次数后会使用信号量进行等待），支持超时
支持Vcpkg方式安装，如vcpkg install cpp-ipc

使用方法

详见：Wiki

性能

环境	值
设备	联想 ThinkPad T450
CPU	英特尔® Core™ i5-4300U @ 2.5 GHz
内存	16 GB
操作系统	Windows 7 Ultimate x64
编译器	MSVC 2017 15.9.4

单元测试和Benchmark测试: test
性能数据: performance.xlsx

参考

cpp-ipc's People

Contributors

Stargazers

Watchers

Forkers

killvxk linecode cx421774557 beratkirik yangguang0756 how0723 19317362 xjump daishengdong afterc ylshan chenyuchenyy 5455945 ghostsofhiroshima alan0526 yumathecompanion chriscanossi msoft1115 vvhh2002 shanewfx lxlyh dongwl zzmcdc swiftlc asdlei99 wlm328cs drivestudy tchernitski czhzng wldp bobdeng1974 dianbian jasonzhoudp xiaobfly saikiranbollu email2hf zsacul zhangmenghe arnoxinglei littleboys bdong1988 czlitony kipade lsaejn dotkt wizardst supersonic0410 matrixkung kylinxh dreamplayer-zhang radiateq zhjf0111 w1146869587 johngladp bastedru wuht007 yongxin-ms sshsu 3xlogickevinhan kitfung jiajuns koobin huang-jf gavinge nehcuh nicai0609 skyformat99 helongjoy nickhuangxinyu soietre zmf2022 oldyang1983 ideorg wuyadie sulijiang lsclone renecn sl-gong liangkdm zesonglee jsho000 metin3407 bytexiaotang cetcjinjian org-mars uknowxk zeta1999 lbfing liaoshuren msnh2012 iomeone crackercat ssh352 mincyu aruanruan 378281820qq zkas brinkqiang2cpp liuyf5231 malanglanggit

cpp-ipc's Issues

Large message sending error with multiple receivers in unicast mode

在unicast模式下，当存在多个接收者时，大小超过large_msg_limit的数据包在拼包时会错乱。

原因：

拼包逻辑没考虑unicast模式，这种模式下每个接收者各自消费的消息，其它接收者就看不到了

options for set the linking static or shared

Hello,

thanks for your library who is working very well

btw can you add an options in the CMakeList.txt for have shared or static linking for the lib ?

Thanks

windwos vs2019 X86 引用ipc.lib报错

error LNK2019: 无法解析的外部符号 "__declspec(dllimport) public: static bool __cdecl ipc::chan_impl<struct ipc::wr<1,1,1> >::send(void *,void const *,unsigned int)" (_imp?send@?$chan_impl@U?$wr@$00$00$00@ipc@@@ipc@@SA_NPAXPBXI@Z)，函数 "public: bool __thiscall ipc::chan_wrapper<struct ipc::wr<1,1,1> >::send(void const *,unsigned int)" (?send@?$chan_wrapper@U?$wr@$00$00$00@ipc@@@ipc@@QAE_NPBXI@Z) 中引用了该符号

带timeout的recv，在遇到send时会消耗大量cpu

原因：waiter_helper 中的 wait_if 对 counter 的计数存在 bug，在 timeout 时会出现额外的增长导致 wait 失效。

不同用户进程通信的问题

稍微看了下平台相关的部分源码，windows平台下，不同用户进程的通信应该是有权限问题的，比如：SYSTEM用户的进程，与administrator用户的进程。

收取数据包时程序崩溃

您好，我在阅读了您的代码之后，认为比较比较适合我们公司的系统，所以使用您的程序收发一个比较大的数据包，单发多收。
我现在遇到一个问题是，收数据之后node会崩溃。
这是发数据的代码：
ipc::route shm_send_ = ipc::route{"rslidar_packets_pkt"};
rslidar_msgs::rslidarScan scanMsg;
ipc::buff_t outMsgBuf(&send_msg, sizeof(send_msg));
shm_send_.send(outMsgBuf);
收数据的代码是：
ipc::route shm_recv_ = ipc::route{"rslidar_packets_pkt"};
ipc::buff_t buf = shm_recv_.recv();
auto recv_msg_ptr= buf.data<rslidar_msgs::rslidarScan>(); //方式1
//TODO:how to get recv_msg_ptr type is from shm_recv.recv();
rslidar_msgs::rslidarScan * recv_msg_ptr = static_cast<rslidar_msgs::rslidarScan * >(buf.data()); //方式2
通过方式1和方式2收取的数据都会崩溃，麻烦您问一下是什么原因呢？

fail: send, there is no receiver on this connection.

Hi,
While I use this demo code, I found if the received crashed and reopen it again, I usually get this error and can not get any message anymore, I need to reboot my device to recovery it.
is it the exist issue or limitation? or anything I need to handle on the code?

[code version]
commit 647f7a2
[Step]

launch process A
launch process B
process B crashed
reopen process B

mmb模式下，receiver退出导致多个sender同时出现force-push，会意外断开所有连接

当consumer没收到数据时，一直阻塞

msq_queue的 demo里面

auto msg = que__.recv();当没有数据时，会一直阻塞在这里

可以设置不阻塞吗？

单生产者单消费者send方法崩溃

多进程通信，崩溃点发生在ipc.cpp line:417 code:std::memcpy(buf, data, size)，看起来像是越界了

clean up on destruction

Due to statically declared objects, some artifacts aren't removed from /dev/shm when the ipc::chan object is destroyed.

Steps to reproduce:
Attached sample code: ipc_plain.cpp.txt

Place breakpoint at line 35
Observe contents of /dev/shm:
__IPC_SHM____CHUNK_INFO__1383424 (42MBytes)
__IPC_SHM____CA_CONN __

The two files are deleted only when main() returns.

Add a better disconnector per channel

For now the demo application relies on signal interception to run disconnect(), but I dont think that is very reliable and it doesn't seem to work with NAPI.

很不错的库，是否能支持全英文，上到vcpkg 上！星星至少翻两倍！

Doesn't work when sending std array/vector with ipc

hello,
I tried to send std::vector and std::array with ipc and it doesn't work.
Can I get some help? Maybe there is a way to send vector/array?

Build failed on MacOS

 ✘  ~/github/cpp-ipc/build   master  cmake ..
-- The C compiler identification is AppleClang 12.0.5.12050022
-- The CXX compiler identification is AppleClang 12.0.5.12050022
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/shenzhigang/github/cpp-ipc/build
 ~/github/cpp-ipc/build   master  make
[ 14%] Building CXX object src/CMakeFiles/ipc.dir/libipc/platform/shm_linux.cpp.o
In file included from /Users/shenzhigang/github/cpp-ipc/src/libipc/platform/shm_linux.cpp:20:
In file included from /Users/shenzhigang/github/cpp-ipc/src/libipc/memory/resource.h:14:
In file included from /Users/shenzhigang/github/cpp-ipc/src/libipc/memory/alloc.h:15:
/Users/shenzhigang/github/cpp-ipc/src/libipc/platform/detail.h:59:1: error: deduction guide must be declared in the same scope as template 'std::__1::unique_ptr'
unique_ptr(T* p) -> unique_ptr<T>;
^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/memory:2148:59: note: template is declared here
class _LIBCPP_UNIQUE_PTR_TRIVIAL_ABI _LIBCPP_TEMPLATE_VIS unique_ptr {
                                                          ^
In file included from /Users/shenzhigang/github/cpp-ipc/src/libipc/platform/shm_linux.cpp:20:
In file included from /Users/shenzhigang/github/cpp-ipc/src/libipc/memory/resource.h:14:
In file included from /Users/shenzhigang/github/cpp-ipc/src/libipc/memory/alloc.h:15:
/Users/shenzhigang/github/cpp-ipc/src/libipc/platform/detail.h:61:1: error: deduction guide must be declared in the same scope as template 'std::__1::unique_ptr'
unique_ptr(T* p, D&& d) -> unique_ptr<T, std::decay_t<D>>;
^
/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/memory:2148:59: note: template is declared here
class _LIBCPP_UNIQUE_PTR_TRIVIAL_ABI _LIBCPP_TEMPLATE_VIS unique_ptr {
                                                          ^
2 errors generated.
make[2]: *** [src/CMakeFiles/ipc.dir/libipc/platform/shm_linux.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/ipc.dir/all] Error 2
make: *** [all] Error 2
 ✘  ~/github/cpp-ipc/build   master 

断开连接时崩溃

例子里面是这样写的
ipc::route cc{"ipc"};
没问题

但是
char sz[] = {"ipc"};
ipc::route cc;
cc.connect(sz,ipc::sender);
当调用 cc.disconnect() 发生崩溃

关于代码风格问题

虽然在issue下面提出这个问题非常不合适，但是cpp-ipc是一个很好的项目，衷心的希望大家能够一起参与进来讨论学习，所以提起勇气提一个这样的疑惑，我个人c++写的不算多，但是说实在感觉看作者的这个库看起来非常吃力，可能是为了优美很扩展性，很多东西都做了分离，抽象，包装，但是看起来很晦涩，我个人感觉这样的代码风格是否不太友好，是否在工程上不太适合这么写，只是因为这是一个私人开发的库所以这么写吗？

比如，对于下面一个这样的send函数，如果想知道大概做什么，看调用的名字就很清楚，但想要看清楚一些别的东西，比如是怎么发消息的，大文件怎么处理的，怎么同步的，怎么通知等等，这些就要往下面看，但是这种结构往下面看很难受，这18行里面用了4个lambda表达式，就需要带着记忆跳回来看很累，这比直接看会反人类不少(这也可能是因为我本人lambda表达式用的不多的关系不太喜欢这样)；其次在这种结构下，为了扩展性，就必须用auto，auto 虽然能自动推导也很好用，但是用多了，对于代码的阅读性而言，是很受影响的，auto通常都只是在一些明显能看到什么类型的地方使用，不清楚各位用什么看代码，我本人用的是vscode，vscode的定义跳转已经算是好的了，但是这种auto变量的调用是完全没法跳转的，没法直接跳转很多时候就需要手动搜
，一些vim党通常也没有配置ycm这么重的东西去看定义，使用简单的符号跳转，去看在这样的lambda下的auto变量一些调用的一定就更难了

static bool send(ipc::handle_t h, void const * data, std::size_t size) {
    return send([](auto info, auto que, auto msg_id) {  
        return [info, que, msg_id](std::int32_t remain, void const * data, std::size_t size) {
            if (!wait_for(info->wt_waiter_, [&] {
                    return !que->push(info->cc_id_, msg_id, remain, data, size);
                }, default_timeout)) {
                ipc::log("force_push: msg_id = %zd, remain = %d, size = %zd\n", msg_id, remain, size);
                if (!que->force_push([](void* p) {
                    auto tmp_msg = static_cast<typename queue_t::value_t*>(p);
                    if (tmp_msg->storage_) {
                        clear_storage(*reinterpret_cast<std::size_t*>(&tmp_msg->data_), 
                                      static_cast<std::int32_t>(data_length) + tmp_msg->remain_);
                    }
                    return true;
                }, info->cc_id_, msg_id, remain, data, size)) {
                    return false;
                }
            }
            info->rd_waiter_.broadcast();
            return true;
        };
    }, h, data, size);
}

谢谢

怎样清空之前的接收进程?

当之前的接收进展不正常退出时, 此时对应的接收进程没有正常退出, 相应的que__的recv_conn次数也不会下降, 以至达到最大数量32...
有没有方便的接口可以快速清楚之前生成的所有接收进程?

库代码使用的C++语言标准是？

编译这个库需要编译器支持的C++语言标准是什么？
C++11? C++14? C++17?

之所以问这个问题，是因为我使用的编译器是linaro-armv7ahf-2015.11-gcc5.2_v521.tar.xz。应该支持不到太高的C++语言标准。要是只需要支持C++11的话，应该没问题。

是否考虑加入写入互斥

如 demo中的 msg_que,
如果已经执行了一个 msg_que sender 再执行第二个 msg_que sender 时，提示错误，已经存在一个 sender 了。

bug反馈：发送方速度超出接收方时的异常现象

当发送方速度很快，接收方跟不上的时候，接收方会异常阻塞卡死，怀疑是同步控制有问题。
在win平台下，vs2019编译环境，64位debug，创建控制台项目，有如下源代码：
#include
#include
#include
#include
#include "libipc/ipc.h"

constexpr char const name__[] = "ipc-chat";
ipc::channel sender__{ name__, ipc::sender };
ipc::channel receiver__{ name__, ipc::receiver };

int main()
{
std::thread receiver(
{
std::cout << " Start recv.\n";

		while (1)
		{
			ipc::buff_t buf = receiver__.recv(); // 阻塞
			if (buf.empty())
			{
				continue;
			}

			std::string strRecv(buf.get<char const*>(), buf.size());
			if (strRecv == "quit") break;
			std::cout << "Recv:" + strRecv;

			std::this_thread::sleep_for(std::chrono::milliseconds(100));
		}
		std::cout << " receiver is quit...\n";
	});

std::thread sender([]()
	{
		std::cout << " Start send.\n";

		std::string strSend;
		for (int i = 1; i < 10000; ++i)
		{
			strSend = std::to_string(i) + ",________________________________________________.\n";
			sender__.send(strSend.c_str(), strSend.size());
		}

		strSend = "quit";
		while (true)
		{
			bool bSuccess = sender__.send(strSend.c_str(), strSend.size());
			if (bSuccess) break;
		}
		std::cout << " Sender is quit...\n";
	});

receiver.join();
sender.join();
receiver__.disconnect();
sender__.disconnect();
return 0;

}

执行一段时间后，发送会提示：
fail: send, there is no receiver on this connection.
在暂停断点调试，会发现receiver接收线程阻塞在了cpp-ipc\src\libipc\platform\waiter_win.h文件的45行处，永远不退出了，阻塞代码：
switch ((ret = ::WaitForSingleObject(h_, ms))) {

关于以下代码的解读没有弄明白

你好！mutouyun
我在看代码的时候，以下两个代码没有明白，可否帮忙解析一下，谢谢
allloc.h中
static void** node_p(void* node) {
return reinterpret_cast<void**>(node);
}

static auto& next(void* node) {
return *node_p(node);
}

另外内存池中的内存随着数据频率发送的越高，其内存一直在增加，我的程序在引用的时候，每个数据大小概是16w左右/100ms，内存一直持续在增加，达到了1G之上，当暂亭发送的时候，内存池的内存也不见释放。请问这种情况如何处理？
谢谢！

可否提供c++11的版本

可否提供c++11的版本，要求c++17 太高了

to_tchar should accept a UTF-8 string, not ANSI string

to_tchar 函数虽然仅用于windows，但建议作为通用 UTF-8 转 UTF-16 的函数来定义（这样函数名应该调整下）

Compilation errors

Thanks for awesome lib!

I got some compilation error while trying to build, here is how one of them looked like (others were the same nature):
........ In file included from /usr/include/c++/5/bits/stl_pair.h:59:0, from /usr/include/c++/5/bits/stl_algobase.h:64, from /usr/include/c++/5/bits/char_traits.h:39, from /usr/include/c++/5/string:40, from /home/42/cpp-ipc/src/platform/shm_linux.cpp:12: /usr/include/c++/5/bits/move.h: In instantiation of ‘void std::swap(_Tp&, _Tp&) [with _Tp = ipc::mem::allocator_wrapper<char, ipc::mem::static_wrapper<ipc::mem::variable_wrapper<ipc::mem::async_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152ul>, ipc::mem::fixed_expand_policy<8192ul, 2097152ul> >, ipc::mem::default_recycler> > > >]’: /usr/include/c++/5/bits/allocator.h:175:8: required from ‘static void std::__alloc_swap<_Alloc, false>::_S_do_it(_Alloc&, _Alloc&) [with _Alloc = ipc::mem::allocator_wrapper<char, ipc::mem::static_wrapper<ipc::mem::variable_wrapper<ipc::mem::async_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152ul>, ipc::mem::fixed_expand_policy<8192ul, 2097152ul> >, ipc::mem::default_recycler> > > >]’ /usr/include/c++/5/bits/basic_string.tcc:67:50: required from ‘void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::swap(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = ipc::mem::allocator_wrapper<char, ipc::mem::static_wrapper<ipc::mem::variable_wrapper<ipc::mem::async_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152ul>, ipc::mem::fixed_expand_policy<8192ul, 2097152ul> >, ipc::mem::default_recycler> > > >]’ /usr/include/c++/5/bits/basic_string.h:589:2: required from ‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = ipc::mem::allocator_wrapper<char, ipc::mem::static_wrapper<ipc::mem::variable_wrapper<ipc::mem::async_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152ul>, ipc::mem::fixed_expand_policy<8192ul, 2097152ul> >, ipc::mem::default_recycler> > > >]’ /home/42/cpp-ipc/src/platform/shm_linux.cpp:80:15: required from here /usr/include/c++/5/bits/move.h:186:11: error: use of deleted function ‘constexpr ipc::mem::allocator_wrapper<char, ipc::mem::static_wrapper<ipc::mem::variable_wrapper<ipc::mem::async_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152ul>, ipc::mem::fixed_expand_policy<8192ul, 2097152ul> >, ipc::mem::default_recycler> > > >& ipc::mem::allocator_wrapper<char, ipc::mem::static_wrapper<ipc::mem::variable_wrapper<ipc::mem::async_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152ul>, ipc::mem::fixed_expand_policy<8192ul, 2097152ul> >, ipc::mem::default_recycler> > > >::operator=(const ipc::mem::allocator_wrapper<char, ipc::mem::static_wrapper<ipc::mem::variable_wrapper<ipc::mem::async_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152ul>, ipc::mem::fixed_expand_policy<8192ul, 2097152ul> >, ipc::mem::default_recycler> > > >&)’ __a = _GLIBCXX_MOVE(__b); .......

and I fixed it by adding:
tchernitski@b765687

在VS2015上编译有错误，是不是只能在VS2017上编译？

在VS2015上编译有错误，是不是只能在VS2017上编译？
错误信息是：
1>c:\program files (x86)\microsoft visual studio 14.0\vc\include\xmemory0(876): error C2664: 'ipc::mem::allocator_wrapper<U,ipc::mem::limited_recycler<AllocP,true>::fixed_alloc_t>::allocator_wrapper(const ipc::mem::allocator_wrapper<U,ipc::mem::limited_recycler<AllocP,true>::fixed_alloc_t> &) noexcept': cannot convert argument 1 from 'std::_Wrap_alloc<ipc::mem::allocator_wrapper<U,ipc::mem::limited_recycler<AllocP,true>::fixed_alloc_t>>' to 'ipc::mem::limited_recycler<AllocP,true>::fixed_alloc_t &&'

Originally posted by @czhzng in #4 (comment)

如何实现类似c/s架构的通信

mutouyun，
谢谢你分享的这个项目！
目前我有个程序打算使用你的这个项目。
我的程序是同一台机器上上类似C/S的进程间通信。一个Server，多个client，client向server发送请求，server只是被动响应客户端的请求，msg可能会比较大，几百K到几兆。
我希望是每个client和server之间有专用的IPC通道，甚至server可以为每个通道建立专用的thread。
研究了一下，不知道如何建立这样的IPC通道，希望能得到你的指点。
谢谢！
paul

Can't cross compile for android

▶make       
Scanning dependencies of target ipc
[ 14%] Building CXX object src/CMakeFiles/ipc.dir/libipc/platform/shm_linux.cpp.o
In file included from /home/szg/github/cpp-ipc/src/libipc/platform/shm_linux.cpp:20:
In file included from /home/szg/github/cpp-ipc/src/libipc/memory/resource.h:14:
In file included from /home/szg/github/cpp-ipc/src/libipc/memory/alloc.h:15:
/home/szg/github/cpp-ipc/src/libipc/platform/detail.h:59:1: error: deduction guide must be declared in the same scope as template 'std::__ndk1::unique_ptr'
unique_ptr(T* p) -> unique_ptr<T>;
^
/home/szg/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/memory:2396:28: note: template is declared here
class _LIBCPP_TEMPLATE_VIS unique_ptr {
                           ^
In file included from /home/szg/github/cpp-ipc/src/libipc/platform/shm_linux.cpp:20:
In file included from /home/szg/github/cpp-ipc/src/libipc/memory/resource.h:14:
In file included from /home/szg/github/cpp-ipc/src/libipc/memory/alloc.h:15:
/home/szg/github/cpp-ipc/src/libipc/platform/detail.h:61:1: error: deduction guide must be declared in the same scope as template 'std::__ndk1::unique_ptr'
unique_ptr(T* p, D&& d) -> unique_ptr<T, std::decay_t<D>>;
^
/home/szg/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/memory:2396:28: note: template is declared here
class _LIBCPP_TEMPLATE_VIS unique_ptr {
                           ^
/home/szg/github/cpp-ipc/src/libipc/platform/shm_linux.cpp:70:16: error: no member named 'shm_open' in the global namespace
    int fd = ::shm_open(op_name.c_str(), flag, S_IRUSR | S_IWUSR |
             ~~^
/home/szg/github/cpp-ipc/src/libipc/platform/shm_linux.cpp:143:15: error: no member named 'shm_unlink' in the global namespace
            ::shm_unlink(ii->name_.c_str());
            ~~^
/home/szg/github/cpp-ipc/src/libipc/platform/shm_linux.cpp:159:11: error: no member named 'shm_unlink' in the global namespace
        ::shm_unlink(name.c_str());
        ~~^
/home/szg/github/cpp-ipc/src/libipc/platform/shm_linux.cpp:168:7: error: no member named 'shm_unlink' in the global namespace
    ::shm_unlink((ipc::string{"__IPC_SHM__"} + name).c_str());
    ~~^
6 errors generated.
make[2]: *** [src/CMakeFiles/ipc.dir/build.make:63: src/CMakeFiles/ipc.dir/libipc/platform/shm_linux.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:86: src/CMakeFiles/ipc.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

进程同步机制

mutouyun，你好，非常感谢你的开源分享。
因为没有找到相关文档，想请问一下关于进程间同步的问题：

代码中waiter_linux.h用到了pthread_mutex_t ，同时prod_cons.h用到了std::atomic；另外还实现了ipc::spin_lock。请问这三者是否都是用于进程同步的？如果是的话机制有什么区别吗？
后续是否有更加详细的文档或者wiki以供参考学习？

非常感谢！

CMakeLists 没有设置整个库的自动安装

不知道你有没有兴趣加上。如果可以，我可以提交一个PR。

谢谢你的程序。

能否提供更加复杂一点的Sample？

比如想实现类似HTTP请求的功能，需要用到ipc::channel支持多写多读。怎么实现进程1同一时刻多发，进程2同一时刻多收，分发处理，分发响应，不需要Lock？

Arm上貌似不可以哎

Error: selected processor does not support `yield' in ARM mode

Win10下退出时崩溃

在Win下使用此库，退出的时候，会崩，发生在OnThreadExit里面：

 	test-ipc.exe!std::_Iterator_base12::_Adopt(const std::_Container_base12 * _Parent) Line 1237	C++
 	test-ipc.exe!std::_Iterator_base12::operator=(const std::_Iterator_base12 & _Right) Line 1213	C++
 	test-ipc.exe!std::_Iterator_base12::_Iterator_base12(const std::_Iterator_base12 & _Right) Line 1208	C++
 	test-ipc.exe!std::_Tree_unchecked_const_iterator<std::_Tree_val<std::_Tree_simple_types<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>,std::_Iterator_base12>::_Tree_unchecked_const_iterator<std::_Tree_val<std::_Tree_simple_types<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>,std::_Iterator_base12>(std::_Tree_unchecked_const_iterator<std::_Tree_val<std::_Tree_simple_types<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>,std::_Iterator_base12> && __that)	C++
 	test-ipc.exe!std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>>::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>>(std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>> && __that)	C++
 	test-ipc.exe!std::pair<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>>,bool>::pair<std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>>,bool><std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>>,bool const &,0>(std::_Tree_const_iterator<std::_Tree_val<std::_Tree_simple_types<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>> && _Val1, const bool & _Val2) Line 127	C++
 	test-ipc.exe!std::_Tree<std::_Tset_traits<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>,std::less<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>,ipc::mem::allocator_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>,ipc::mem::limited_recycler<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>,1>::fixed_alloc_t<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>,1>>::emplace<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>(ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>> && <_Vals_0>) Line 1096	C++
 	test-ipc.exe!std::multiset<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>,std::less<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>,ipc::mem::allocator_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>,ipc::mem::limited_recycler<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>,1>::fixed_alloc_t<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>>>::emplace<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>>(ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>> && <_Val_0>) Line 257	C++
>	test-ipc.exe!ipc::mem::limited_recycler<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>,1>::collect(ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>> && alc) Line 79	C++
 	test-ipc.exe!ipc::mem::async_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>,ipc::mem::default_recycler>::alloc_proxy::~alloc_proxy() Line 163	C++
 	[External Code]	
 	test-ipc.exe!ipc::tls::pointer<ipc::mem::async_wrapper<ipc::mem::detail::fixed_alloc<ipc::mem::variable_alloc<2097152,ipc::mem::scope_alloc<ipc::mem::static_alloc>>,ipc::mem::fixed_expand_policy<8192,2097152>>,ipc::mem::default_recycler>::alloc_proxy>::<lambda>(void * p) Line 55	C++
 	test-ipc.exe!void <lambda>(void *)::<lambda_invoker_cdecl>(void * p) Line 55	C++
 	test-ipc.exe!ipc::`anonymous namespace'::tls_data::destruct(void * data) Line 36	C++
 	test-ipc.exe!ipc::`anonymous namespace'::clear_all_records() Line 82	C++
 	test-ipc.exe!ipc::`anonymous namespace'::OnThreadExit() Line 155	C++

运行环境是Win10 18362, VS2019 16.3.7 64位，静态链接的库。这是我测试用的工程：
test-ipc.zip

請問目前x86和x64之間是不是不能溝通?

您好，如題，我目前寫了兩個process分別是x86和x64，原本一直想說為何無法溝通成功，後來實驗發現好像只能兩個process要在同cpu架構才能work，想問是不是這是現在這個tool的限制? (我用提供的demo chat也不行)

wait infinite when sender or receiver quit.

反馈个特别的使用场景，看是否是个问题？

Windows下，当sender or receiver任意一端异常退出时，且未调用disconnect(),
此时，另外一端调用recv() 和 send()会一直wait下去，ipc::recv_count()也未发生变化。
必须重启sender和receiver后才能正常工作。

如何缩短延迟

测试系统 cpu 3.7g ，平均每次收发 1024字节的数据，延迟在 1.4us左右，可以进一步缩短延迟吗?

send/recv的时序有要求么？

我想问一下在使用ipc::channel的时候，是不是一方的recv必须在另一方的send之前调用？
我测试了下Tutorial中的ipc::channel的例子，一旦在thread producer的cc.recv调用之前加入一个sleep，那么就收不到消息了，而且奇怪的是对应的consumer方调用的send依然会返回成功？

测试代码如下：

int main()
{
    using namespace std::literals;

    std::vector<char const*> const datas = {
    "hello!",
    "foo",
    "bar",
    "ISO/IEC",
    "14882:2011",
    "ISO/IEC 14882:2017 Information technology - Programming languages - C++",
    "ISO/IEC 14882:2020",
    "Modern C++ Design: Generic Programming and Design Patterns Applied"
    };

    // thread producer
    std::thread t1{ [&] {
        ipc::channel cc { "my-ipc-channel" };
        for (std::size_t i = 0; i < datas.size(); ++i) {
            // try sending data
            while (!cc.send(datas[i])) {
                // waiting for connection
                cc.wait_for_recv(1);
            }
            std::this_thread::sleep_for(1s);
            // recv ack
            std::printf("1 recving\n");
            auto dd = cc.recv();
            auto str = static_cast<char*>(dd.data());
            if (str == nullptr) {
                std::printf("ack: error!\n");
            }
            else {
                std::printf("ack: %c\n", str[0]);
            }
        }
        // quit
        cc.send(ipc::buff_t('\0'));
    } };

    // thread consumer
    std::thread t2{ [&] {
        ipc::channel cc { "my-ipc-channel" };
        while (1) {
            std::printf("2 recving\n");
            auto dd = cc.recv();
            auto str = static_cast<char*>(dd.data());
            if (str == nullptr || str[0] == '\0') return;
            std::printf("2 recv: %s\n", str);
            // try sending ack
            while (!cc.send(ipc::buff_t('a'))) {
                // waiting for connection
                cc.wait_for_recv(1);
            }
        }
    } };

    t1.join();
    t2.join();
}

msg_que_t 改为 multi - multi - unicast
打开一个 s 端打开一个 r 端（速度正常）
再打开一个 r 端，速度下降得非常多

对比：
打开多个 s 端，1个r端，速度正常