In a multi-threaded fork process, child processes may be stuck by locks
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 process v2 child creation and the notify_fork call stack described in the report, then inspect how boost::asio::detail::signal_state and its mutex are used across fork. Reproduce on Darwin with four concurrent creator threads and verify that child processes no longer remain blocked while preserving lock safety.
Written by the indexing model from the issue text.
Description
system: Darwin Kernel Version 22.5.0
boost version: 1.85.0
When I use the process v2 version of the library to create child processes to perform tasks, when multiple threads create processes at the same time, there is a high probability that one of the processes will get stuck.
This is my experimental results chart：
Here we start 4 threads, and then each thread uses process v2 to create a child process at the same time.
In this figure, process 37673 is blocked.
Running lldb, you can see that the call stack of process 37673 is as shown in the following figure. You can see that the process is waiting for a lock. From frame 9, it can be seen that the sub-process is stuck in the notify_fork operation, and the operation inside is stuck while obtaining the lock.
Here is the stuck position, I try to add it before this sentence.
I try to manually release the lock here first, and this problem can be solved. The code is as follows：
boost::asio::detail::signal_state *state = boost::asio::detail::get_signal_state();
state->mutex_.unlock();
- Dominant language
- C++
- Stars
- 145
- Forks
- 151
- 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/process
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
All issues in boostorg/process
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
duckdb/duckdb-wasm#2258 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
objectionary/eo-graphs#75 ·
-
Coarray integration tests carry no LABELS, so run_tests.py silently skips them under every backend Opencoarray
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
FISCO-BCOS/FISCO-BCOS#5642 ·