Hello,
I waited for today to recheck my findings on a different system with
'official' msysgit binaries:
On Sun, Jul 13, 2008 at 10:32 PM, Johannes Schindelin
<[EMAIL PROTECTED]> wrote:
> On Sun, 13 Jul 2008, Alexander Gavrilov wrote:
>> OK, so I run 'git gui blame SomeFile' in one window, and look at the list
>> of processes from another one. Here it is, with irrelevant parts removed:
>>
>> $ ps -W
>> PID PPID PGID WINPID TTY UID STIME COMMAND
>> 904 1 904 904 con 500 14:38:44 /bin/bash
>> 1008 904 1008 1008 con 500 18:11:20 /bin/git
>> (bash.exe)
>> 976 0 0 976 ? 0 18:11:20
>> c:\msysgit\bin\git.exe
>> 344 1 344 344 con 500 18:11:20 /mingw/bin/wish
>> (sh.exe)
>> 1104 0 0 1104 ? 0 18:11:20
>> c:\msysgit\mingw\bin\wish.exe
>> 736 0 0 736 ? 0 18:11:45
>> C:\msysgit\bin\git-blame.exe
>>
>> (In parentheses I specified what Task Manager thinks about the process)
>>
>> I can kill 1008 and 344, and it cascades to 976 and 1104 respectively.
>> But 736 continues running and hogging the CPU, and when I try to kill it, I
>> get:
>>
>> $ kill 736
>> bash: kill: (736) - No such process
>
> Can you look at the implementation of kill.exe and find out why it does
> that?
kill.exe (and kill builtin in bash) just calls the 'kill' system call,
which is emulated by msys.
Signal emulation in cygwin and mingw is done on the receiving side by
allocating a shared
memory area, named sprintf("cygpid.%x",pid), plus a named semaphore
for communication,
and starting a listener thread. The sender queues the signal and
raises the semaphore to
notify the target.
Now, what I can see is that for some reason git binaries don't even
bother initializing their
receiving infrastructure. When they are called from the shell, bash
first forks, creating a
helper process (winpid 1008 & 344 in the list above), and then
emulates exec by starting
the intended binary as a separate process, changing the cygwin process
name to reflect it,
and waiting for the newly-created process to finish. In this case, the
helper process receives
the signal and apparently automatically terminates the worker process.
On the other hand, when the git binaries are started from native
windows programs (e.g. cmd),
or wish, there is no helper, so the program should receive the signals
itself. Which it does not --
in fact, I cannot see any relevant opened shared object handles in
Process Explorer.
So, kill tries to open the 'cygpid.PID' memory area, fails, and
declares that the process does not exist.
P.S. From the sources I understood that even in the exec case the
worker process should
setup a cygpid area that forwards from its winpid to the real PID of
the impersonating helper
process -- and it doesn't do that. So it seems that something is
fundamentally broken.
Alexander
