aboutsummaryrefslogtreecommitdiff
path: root/winsup/cygwin/dcrt0.cc
diff options
context:
space:
mode:
authorCorinna Vinschen <corinna@vinschen.de>2019-01-31 21:19:03 +0100
committerCorinna Vinschen <corinna@vinschen.de>2019-02-01 20:06:47 +0100
commitb5e1003722cb14235c4f166be72c09acdffc62ea (patch)
treed40d52854872cbe014a8c980bf1ccbb208677e28 /winsup/cygwin/dcrt0.cc
parentc0b9f600f9ce6753545f4df7967cffe1bb867488 (diff)
downloadnewlib-b5e1003722cb14235c4f166be72c09acdffc62ea.zip
newlib-b5e1003722cb14235c4f166be72c09acdffc62ea.tar.gz
newlib-b5e1003722cb14235c4f166be72c09acdffc62ea.tar.bz2
Cygwin: processes: use dedicated Cygwin PID rather than Windows PID
Using the Windows PID as Cygwin PID has a few drawbacks: - the PIDs on Windows get reused quickly. Some POSIX applications choke on that, so we need extra code to avoid too quick PID reuse. - The code to avoid PID reuse keeps parent process handles and (depending on a build option) child processes open unnecessarily. - After an execve, the process has a split personality: Its Windows PID is a new PID, while its Cygwin PID is the PID of the execve caller process. This requires to keep two procinfo shared sections open, the second just to redirect process info requests to the first, correct one. This patch changes the way Cygwin PIDs are generated: - Cygwin PIDs are generated independently of the Windows PID, in a way expected by POSIX processes. The PIDs are created incrementally in the range between 2 and 65535, round-robin. - On startup of the first Cygwin process, choose a semi-random start PID for the first process in the lower PID range to make the PIDs slightly unpredictable. This may not be necessary but it seems kind of inviting to know that the first Cygwin process always starts with PID 2. - Every process not only creates the shared procinfo section, but also a symlink in the NT namespace, symlinking the Windows PID to the Cygwin PID. This drops the need for the extra procinfo section after execve. - Don't keep other process handles around unnecessarily. - Simplify the code creating/opening the shared procinfo section and make a clear distinction between interfaces getting a Cygwin PID and interfaces getting a Windows PID. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Diffstat (limited to 'winsup/cygwin/dcrt0.cc')
-rw-r--r--winsup/cygwin/dcrt0.cc27
1 files changed, 5 insertions, 22 deletions
diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index 463df31..5cdf01c 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -687,28 +687,11 @@ child_info_spawn::handle_spawn ()
if (child_proc_info->parent)
{
- if (type == _CH_EXEC)
- {
- /* Keep pointer to parent open if we've execed so that pid will not be
- reused. Try to Urther reduce permissions. */
- HANDLE new_parent;
-
- if (DuplicateHandle (GetCurrentProcess (), child_proc_info->parent,
- GetCurrentProcess (), &new_parent,
- SYNCHRONIZE, FALSE, 0))
- {
- CloseHandle (child_proc_info->parent);
- child_proc_info->parent = new_parent;
- }
- }
- else
- {
- /* Otherwise, we no longer need this handle so close it. Need to do
- this after debug_fixup_after_fork_exec or DEBUGGING handling of
- handles might get confused. */
- CloseHandle (child_proc_info->parent);
- child_proc_info->parent = NULL;
- }
+ /* We no longer need this handle so close it. Need to do
+ this after debug_fixup_after_fork_exec or DEBUGGING handling of
+ handles might get confused. */
+ CloseHandle (child_proc_info->parent);
+ child_proc_info->parent = NULL;
}
signal_fixup_after_exec ();