named_condition_any does not appear to notify
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- operating-systems
Research direction
Start with the reproducer and compile it on Linux against Boost 1.68.0. Compare the behavior and implementation paths for boost/interprocess/sync/named_condition_any.hpp and named_condition.hpp, then verify that the child receives notifications when named_condition_any is used, including timed waits.
Written by the indexing model from the issue text.
Description
I haven't been able to get named_condition_any objects to work on Linux with Boost 1.68.0. Below is code to replicate. When using a named_condition_any the child process will never receive the notification, when using just a named_condition the child process receives the notifications.
#include <boost/interprocess/sync/named_condition_any.hpp>
#include <boost/interprocess/sync/named_condition.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
#include <boost/thread/thread_time.hpp>
#include <unistd.h>
#include <chrono>
#include <thread>
#include <iostream>
namespace ip = boost::interprocess;
int main()
{
typedef ip::named_mutex mutex_type;
//typedef ip::named_condition condition_type;
typedef ip::named_condition_any condition_type;
mutex_type::remove("test_mutex");
condition_type::remove("test_condition");
pid_t pid = fork();
if(pid == 0)
{ // parent process
mutex_type mutex(ip::open_or_create, "test_mutex");
condition_type condition(ip::open_or_create, "test_condition");
while(true)
{
std::this_thread::sleep_for(std::chrono::seconds(1));
std::cout << "signaling children" << std::endl;
condition.notify_all();
}
}
else if(pid > 0)
{ // child process
mutex_type mutex(ip::open_or_create, "test_mutex");
condition_type condition(ip::open_or_create, "test_condition");
while(true)
{
boost::posix_time::ptime wait_time(boost::get_system_time() +
boost::posix_time::seconds(10));
ip::scoped_lock<ip::named_mutex> lock(mutex);
if(condition.timed_wait(lock, wait_time))
std::cout << "got signal from parent" << std::endl;
else
std::cout << "timeout" << std::endl;
}
}
else
{
std::cout << "failed to fork: " << pid << std::endl;
return 1;
}
return 0;
}
- Dominant language
- C++
- Stars
- 185
- Forks
- 131
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from boostorg/interprocess
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
boostorg/interprocess#196 · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
boostorg/interprocess#279 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
boostorg/interprocess#274 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 28/100
boostorg/interprocess#268 · 4 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
boostorg/interprocess#262 · 2 comments ·
All issues in boostorg/interprocess
Similar issues
-
AuTest Bug Tests
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/trafficserver#13714 ·
-
bug build
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
facebookincubator/velox#19143 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
tenstorrent/tt-metal#57393 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
objectionary/eo-graphs#74 ·