tests: fix conflict between Cygwin/msys and Windows PIDs#5188
Closed
mback2k wants to merge 4 commits intocurl:masterfrom
Closed
tests: fix conflict between Cygwin/msys and Windows PIDs#5188mback2k wants to merge 4 commits intocurl:masterfrom
mback2k wants to merge 4 commits intocurl:masterfrom
Conversation
Member
Author
|
TODO: I guess |
mback2k
force-pushed
the
fix-cygwin-msys-pid-conflicts
branch
from
ab911df to
dee3288
Compare
Member
|
Just FYI Windows PIDs are often over 65535 on Enterprise systems that churn a lot of processes. |
Member
|
According to some sources a Windows pid can be anything within 32bit... |
Member
Author
|
Yes, Windows PIDs can be anything, but Cygwin/msys PIDs are generated below 65536 at the moment. So offsetting Windows PIDs by 65536 to have separate "namespaces" will work until they are generated below MAX_INT-65536. Actually I have seen exactly that stackoverflow question, too. I was initially thinking about using negative values for native Windows PIDs, but that would require investigation of changes to some 500 LoCs in the Perl scripts. |
mback2k
force-pushed
the
fix-cygwin-msys-pid-conflicts
branch
3 times, most recently
from
6a0672f to
38d018e
Compare
Add 65536 to Windows PIDs to allow Windows specific treatment. See also: - https://cygwin.com/git/?p=newlib-cygwin.git;a=commit; ↵ h=b5e1003722cb14235c4f166be72c09acdffc62ea - https://cygwin.com/git/?p=newlib-cygwin.git;a=commit; ↵ h=448cf5aa4b429d5a9cebf92a0da4ab4b5b6d23fe Replaces curl#5178
Since the Windows versions of both programs would write Windows PIDs to their pidfiles which we cannot handle, we need to use our known perl.exe Cygwin/msys PID together with exec() in order to tie the spawned processes to the existance of our perl.exe The perl.exe that is executing secureserver.pl and sshserver.pl has a Cygwin/msys PID, because it is started inside Cygwin/msys.
mback2k
force-pushed
the
fix-cygwin-msys-pid-conflicts
branch
from
38d018e to
055b7b2
Compare
MarcelRaad
reviewed
Apr 11, 2020
mback2k
added a commit
that referenced
this pull request
Apr 11, 2020
mback2k
added a commit
that referenced
this pull request
Apr 11, 2020
Since the Windows versions of both programs would write Windows PIDs to their pidfiles which we cannot handle, we need to use our known perl.exe Cygwin/msys PID together with exec() in order to tie the spawned processes to the existance of our perl.exe The perl.exe that is executing secureserver.pl and sshserver.pl has a Cygwin/msys PID, because it is started inside Cygwin/msys. Related to #5188
mback2k
added a commit
that referenced
this pull request
Apr 11, 2020
Avoid potential overflow of huge PIDs on Windows. Related to #5188 Assisted-by: Marcel Raad
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add 65536 to Windows PIDs to allow Windows specific treatment in POSIX Perl based test suite.
See also:
Replaces #5178
This will hopefully fix the random issues encountered with Windows CI builds as described in #5034.