On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
> > The particular deficiency is that when a signal is raise()d whose SIG_DFL
> > action will cause process death (SIGTERM in this case), the
> > implementation of raise() just calls exit(3).
>
> After a bit of web searching, it seems to me that this behaviour of
> raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls
> that. In other words, "the implementation of raise()" is at an even
> lower level than mingw/msys, and I would agree that it is a platform
> issue.
Yeah, if it were mingw_raise responsible for this, I would suggest using
the POSIX shell "128+sig" instead. We could potentially check for
SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if
that would create headaches or confusion for other msys programs,
though. I'd leave that up to the msysgit people to decide whether it is
worth the trouble.
[1] I'd use sigaction to do that on POSIX, but I would not be surprised
to find that there is no support for it in msys. :)
> I tried to summarize the issue for end-user documentation and came
> up with this:
>
> The Git implementation on MinGW exits with status code 3 upon
> receiving an uncaught process-terminating signal, just like any
> program that link with msvcrt (Microsoft C Runtime library)
> whose raise() implementation just calls exit(3). This is
> different from Git on POSIX, which reports a death by receiving
> a signal with the exit status code (128 + signal number).
>
> But when stated this way, it feels that it belongs to Msysgit
> documentation, not ours, at least to me.
Yeah, I think I agree.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
