V2 overwrites SIGCHLD handler without calling previous one
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- operating-systems
Research direction
Compare v2's SIGCHLD handling with the cited v1 files, include/boost/process/v1/detail/posix/wait_for_exit.hpp and sigchld_service.hpp, and review the Asio basic_signal_set constraints. Determine whether v2 can preserve or coordinate with an application's existing SIGCHLD handler on RHEL 8; done requires an agreed implementation or documented compatibility decision.
Written by the indexing model from the issue text.
Description
We're using boost::process in a library to spawn a process. We use RHEL 8, so no pidfd, unfortunately.
This library is used in an executable that spawns its own child processes and thus installs its own SIGCHLD handler.
It seems that in v2, the boost::process / boost::asio signal handler completely overwrites the application signal handler, which leads to havoc, since the main application does not notice its child processes exiting anymore...
Asio docs for basic_signal_set say (https://live.boost.org/doc/libs/1_86_0/doc/html/boost_asio/reference/basic_signal_set.html#boost_asio.reference.basic_signal_set.multiple_registration_of_signals):
The application must not also register a signal handler using functions such as signal() or sigaction().
This makes the use of basic_signal_set unacceptable in a library IMO.
In v1, there was some effort, to call the previous signal handler as well: https://github.com/boostorg/process/blob/55e24609671859626caa39c3502fd12df52aee3b/include/boost/process/v1/detail/posix/wait_for_exit.hpp#L68-L69
However, there's also use of asio::signal_set in sigchld_service: https://github.com/boostorg/process/blob/55e24609671859626caa39c3502fd12df52aee3b/include/boost/process/v1/detail/posix/sigchld_service.hpp#L28
In any case, we managed to use v1 for our use-case. But I think it's currently impossible to use boost process v2 for our use case...
Do you agree or am I missing something?
Are there any plans to make v2 usable in a library, where full control over signal handlers cannot be assumed?
- 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 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/cuda-samples#453 ·