listing pids in user session have inconsistent inclusion of kernel threads across platforms
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- cpp
- Domain
- operating-systems
Research direction
Start by reviewing the cross-platform APIs for getting all PIDs, child PIDs, and parent PIDs, focusing on how each platform treats kernel threads and PID 0. The issue is complete when the project has a decided, consistent API policy for system-level processes versus user-level processes and the implementation plan reflects that choice.
Written by the indexing model from the issue text.
Description
I've come to realize the reason why some platforms include a pid of zero in the running process id list, while others don't, is because I incorrectly, and inconsistently, wrote the cross-platform api's for getting all pids, child pids, and parent pid, to include kernel threads on some platforms, while on other platforms, kernel threads are excluded from the list. The solution is not to forcefully prepend a pid of zero to the list when the underlying api omits it, even though this is what we are currently doing. Either include kernel threads or don't.
This means we need to choose which way of doing this we want to support:
- include kernel threads / system-level processes + user-level processes
- user-level processes only
- provide both 1. and 2. but as two separate api's.
What do you think would be the best approach? I'll create a pull request based on what you say.
This is the most portable way of omitting kernel threads, (pseudo-code), because kernel threads have no cmdline or exe path:
struct is_kernel_thread {
bool operator()(proc_id_t proc_id) {
return (cmdline_from_proc_id(proc_id).empty() && exe_from_proc_id(proc_id).empty());
}
};
vec.erase(std::remove_if(vec.begin(), vec.end(), is_kernel_thread()), vec.end());
As you are probably aware this requires a lot of string allocation and is very slow. There are better ways, but they require a lot more code to implement because it would need platforms specifics not already present in the codebase. For example, NetBSD has the P_SYSTEM flag you can check against the p_flag member of struct kinfo_proc * and that can be used to determine whether a given process id you iterate over is considered a kernel thread or not. Other *BSD's have similar approaches we can take.
- 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 3/5 1-2 days Newbie friendliness 65/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 ·