Boost C++ 库

Boost.Interprocess 使用 Windows COM 库实现某些功能，并使用并发模型COINIT_APARTMENTTHREADED对其进行初始化。如果调用线程已为其他并发模型初始化了 COM 库，Boost.Interprocess 将优雅地处理这种情况，并使用已初始化模型的 COM 调用。如果由于某种原因，您希望 Boost.Interprocess 使用其他模型初始化 COM 库，请在包含 Boost.Interprocess 之前定义宏 BOOST_INTERPROCESS_WINDOWS_COINIT_MODEL 为以下值之一：

共享内存（shared_memory_object）在 Windows 中使用内存映射文件实现，这些文件放置在共享文档文件夹中的共享目录中（SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData）。此目录名称是通过会话管理器的注册表值获得的最后一次启动时间。自 Boost 1.74 起，此行为为默认行为。

旧版 Boost.Interprocess（直到 Boost 1.48）使用 COM 调用（通过宏 BOOST_INTERPROCESS_BOOTSTAMP_IS_LASTBOOTUPTIME），但该时间戳在虚拟机和时间调整中不可靠。直到（Boost 1.74）的后续版本使用 EventLog 启动事件作为时间戳，但一些用户发现，如果系统运行时间较长，则 Event Log 中可能缺少此事件。您可以通过定义 BOOST_INTERPROCESS_BOOTSTAMP_IS_EVENTLOG_BASED 来强制使用基于 Event Log 的时间戳。

在任何错误情况下（未定义共享文档文件夹或无法获得启动时间），库都会抛出错误。您仍然可以通过定义您自己的目录作为共享目录来使用 Boost.Interprocess。当您的共享目录是编译时常量时，在使用库时定义 BOOST_INTERPROCESS_SHARED_DIR_PATH（以及 Windows 系统中的 BOOST_INTERPROCESS_SHARED_DIR_WPATH），该路径将用于放置共享内存文件。当您必须在运行时确定共享目录时，定义 BOOST_INTERPROCESS_SHARED_DIR_FUNC 并实现以下函数：

namespace boost {
    namespace interprocess {
        namespace ipcdetail {
            void get_shared_dir(std::string &shared_dir);
            //wstring overload is only needed for Windows systems
            void get_shared_dir(std::wstring &shared_dir);
        }
    }
}

如果定义了 BOOST_USE_WINDOWS_H，则包含 <windows.h> 和其他 Windows SDK 文件，否则库将声明所需的函数和结构以减少包含这些大型头文件的的影响。

在没有 POSIX 共享内存支持的系统上，共享内存对象实现为内存映射文件，使用放置在“/tmp”中的目录，该目录可以包含（如果定义了 BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME）最后一次启动时间（如果操作系统支持）。与 Windows 一样，在获取此目录出现任何错误的情况下，库都会抛出错误。当您的共享目录是编译时常量时，在使用库时定义 BOOST_INTERPROCESS_SHARED_DIR_PATH，该路径将用于放置共享内存文件。当您必须在运行时确定共享目录时，定义 BOOST_INTERPROCESS_SHARED_DIR_FUNC 并实现该函数：

namespace boost {
    namespace interprocess {
        namespace ipcdetail {
            void get_shared_dir(std::string &shared_dir);
        }
    }
}

已提交的地址空间是内核可能必须提供的虚拟内存总量（交换空间或物理内存/RAM），如果所有应用程序都决定访问它们从内核请求的所有内存，则会发生这种情况。默认情况下，Linux 允许进程提交比系统中可用的虚拟内存更多的虚拟内存。如果未访问该内存，则实际上不会使用物理内存 + 交换空间。

这种行为的原因是 Linux 尝试优化 fork 进程的内存使用；fork() 创建进程空间的完整副本，但是使用内存超额提交，在此新的 fork 实例中，只有已被写入的页面才需要内核分配。如果应用程序访问的内存超过可用内存，则内核必须以硬方式释放内存：OOM（内存不足）杀手选择一些进程以杀死以恢复内存。

Boost.Interprocess 无法更改此行为，并且用户在访问共享内存时可能会遇到 OOM 杀手。根据 内核文档，Linux 内核支持几种内存超额提交模式。如果您在应用程序中需要非终止保证，则应更改此内存超额提交行为。

从 FreeBSD 11 开始，声明宏 _POSIX_THREAD_PROCESS_SHARED。但是，默认行为与 Linux 上的行为不同。如果您想使用此功能，根据 libthr(3) 的手册页，您应该检查 sysctl 的 kern.ipc.umtx_vnode_persistent

如果您希望映射文件在最后一个句柄关闭后仍然可用，请将此变量设置为 1。

Boost.Interprocess 在 macOS 中使用 POSIX 共享内存来实现共享内存类。

但是，沙盒应用程序无法使用 System V (XSI) 信号量和 POSIX 信号量，并且默认情况下无法使用共享内存。但是，通过指定请求应用程序组成员资格的权利，应用程序可以使用这些技术与该应用程序组的其他成员进行通信。

请参阅 Apple 文档 了解有关如何在沙盒应用程序上使用进程间通信的限制和指南。

共享互斥锁和共享条件的Win32版本基于“自旋和等待”原子指令。这会导致性能低下，并且不会管理任何诸如优先级反转之类的问题。我们需要线程专家在这方面提供非常重要的帮助。我不确定这是否可以在用户级软件中实现。基于Posix的实现使用PTHREAD_PROCESS_SHARED属性将互斥锁放置在共享内存中，因此没有此类问题。我不知道有任何模拟Win32的PTHREAD_PROCESS_SHARED属性的实现。我们应该能够在内存映射文件中构造这些原语，以便我们可以像使用POSIX原语一样获得文件系统持久性。

目前Interprocess只允许char作为基本命名对象的名称。但是，一些操作系统使用wchar_t作为资源名称（例如，映射文件）。将来，Interprocess应该尝试提供一个可移植的窄/宽字符接口。为此，使用boost wstring <-> string转换实用程序以可移植的方式转换资源名称（转义可能与操作系统名称冲突的字符）将很有用。使用boost::filesystem路径来避免操作系统特定问题也很有趣。

Boost.Interprocess没有为共享内存和同步对象定义安全属性。标准C++也忽略了文件的安全属性，因此添加安全属性需要一些认真工作。

Boost.Interprocess提供了一个基于Boost.Interprocess原语（如互斥锁和条件）的进程共享消息队列。我想开发更多机制，例如面向流的命名FIFO，以便我们可以将其与iostream接口包装器一起使用（我们可以模拟Unix管道）。

C++需要更复杂的机制，在C++中拥有面向流和数据报的面向PF_UNIX的机制将会很好。对于非常快速的进程间远程调用，Solaris doors是为C++实现的一个有趣的替代方案。但是实现类似PF_UNIX的套接字和门的这项工作将是巨大的（并且在用户级库中可能很困难）。有没有网络专家志愿者？