interprocess
interprocess copied to clipboard
boostorg
Boost.org interprocess module
This fixes https://github.com/boostorg/interprocess/issues/192 and https://github.com/boostorg/interprocess/issues/210 (which seem to describe the same bug). Here's the code I'm testing this on. I'm using VS 2022 (though some coworkers with the same compiler...
Since C++20 with std:jthread, there is support for stop tokens in condition variables. It would be nice if the interprocess condition variables would support them, too!
When trying to grow the shared memory that is using raw pointers (instead of boost::interprocess::offset_ptr) the grow() function blocks and never returns. How to reproduce: ``` #include #include #include #include...
Reported in the Boost mailing list: https://lists.boost.org/boost-users/2024/05/91583.php Apparently the boost::flyweight::intermodule_holder on LINUX is creating shared memory objects, which by accident (crash?) can persist after the process having created them is...
As shown in [this CI job](https://github.com/boostorg/flyweight/actions/runs/10861565047/job/30143618327) from Boost.Flyweight: ``` 2024-09-14T10:12:05.5807995Z gcc.compile.c++ bin.v2\libs\flyweight\test\test_intermod_holder.test\gcc-8\debug\x86_64\cxxstd-14-iso\threadapi-win32\threading-multi\visibility-hidden\test_intermod_holder.o 2024-09-14T10:12:05.8093853Z gcc.compile.c++ bin.v2\libs\flyweight\test\test_no_locking.test\gcc-8\debug\x86_64\cxxstd-14-iso\threadapi-win32\threading-multi\visibility-hidden\test_no_locking_main.o 2024-09-14T10:12:08.2337843Z gcc.link bin.v2\libs\flyweight\test\test_intermod_holder.test\gcc-8\debug\x86_64\cxxstd-14-iso\threadapi-win32\threading-multi\visibility-hidden\test_intermod_holder.exe 2024-09-14T10:12:08.2709878Z testing.capture-output bin.v2\libs\flyweight\test\test_intermod_holder.test\gcc-8\debug\x86_64\cxxstd-14-iso\threadapi-win32\threading-multi\visibility-hidden\test_intermod_holder.run 2024-09-14T10:12:08.2711770Z ====== BEGIN OUTPUT ====== 2024-09-14T10:12:08.2720797Z libs/flyweight/test/test_intermod_holder.cpp(33): test 'str==intermodule_flyweight_string("boost")'...
This might be a duplicate of #88, but just in case, I'm opening this separate issue for it. Here is a complete repro, at least on my M1 MacBook with...
When using a message_queue, if a process exits or crashes and then restarts, it can cause another process to enter into an infinite wait state. waiting at: [`p_hdr->m_cond_send.notify_one();`](https://github.com/boostorg/interprocess/blob/develop/include/boost/interprocess/ipc/message_queue.hpp#L1071)
I found some typos in https://www.boost.org/doc/libs/1_87_0/doc/html/interprocess/quick_guide.html , e.g.: ```cpp int main (int argc, char *[2] "MyName"[]) ``` `"MyName"` is used instead of `argv` in main() signature (and in another places)....
…a fixed binary format The windows_bootstamp clasa uses a simple C style string so that the binary format is the same in debug and release builds There can be multiple...
[Linux](https://linux.die.net/man/2/mremap), [NetBSD](https://man.freebsd.org/cgi/man.cgi?query=mremap&apropos=0&sektion=0&manpath=NetBSD+10.1&arch=default&format=html) and [Solaris](https://docs.oracle.com/cd/E88353_01/html/E37841/mremap-2.html) have a `mremap` system call that allows to opportunistically grow or relocate the existing memory mapping. There also seems to be a way to achieve this...
