[windows] try to fix hanging processes#134
Conversation
mamaorha
force-pushed
the
ms/windows/hang
branch
from
3bdb2c5 to
7d541e4
Compare
mamaorha
force-pushed
the
ms/windows/hang
branch
from
7d541e4 to
ff386f4
Compare
ckreibich
left a comment
ckreibich
left a comment
There was a problem hiding this comment.
Just one minor nit Maor, and one question since I don't know the Windows world in /proc at all.
| # Also record the child's MSYS PID. btest-bg-wait can use this to | ||
| # look up the *current* Windows PID via /proc at kill time, which is | ||
| # more reliable than .winpid because exec may change the Windows PID. | ||
| echo $pid >.child_pid |
There was a problem hiding this comment.
Since we're only using this on Windows, how would you feel about moving this up into the the if-block and naming the file ".winchildpid" or some such? I bring this up mainly because Windows support adds a fair bit of complexity to these already hairy scripts, so it helps to explain why the files are there.
| fi | ||
| fi | ||
|
|
||
| # The .winpid captured at startup may hold a stale |
There was a problem hiding this comment.
Is this a "may or may not" for unknown reasons (or perhaps a race condition), or does the /proc/$cpid/winpid case always hold true for Cygwin but not elsewhere and so this is a actually a Cygwin-specific check?
There was a problem hiding this comment.
On Unix, exec() replaces the process image but preserves the PID — that's a fundamental guarantee. Cygwin/MSYS2 can't do that because Windows has no native exec().
Instead, the runtime spawns a new Windows process and terminates the old one. So after exec():
- MSYS/Cygwin PID → stays the same (virtual, tracked by the runtime)
- Windows PID → changes (it's a brand-new native process)
This is exactly why the live /proc/$pid/winpid lookup is needed — .winpid captured the pre-exec Windows PID, which is now dead
2 participants
No description provided.