pthread_sigmask() on windows (wine actualy)

I got this while compiling master today using mingw32 cross toolchain

CC run-command.o
run-command.c: In function 'run_thread':
run-command.c:596:3: warning: implicit declaration of function 'pthread_sigmask' [-Wimplicit-function-declaration] run-command.c:596:23: error: 'SIG_BLOCK' undeclared (first use in this function) run-command.c:596:23: note: each undeclared identifier is reported only once for each function it appears in

This is added in c792d7b (run-command: teach async threads to ignore SIGPIPE - 2016-04-19). From the look of it, wrapping #ifndef GIT_WINDOWS_NATIVE is probably enough? I checked gfw/master too to see how gfw deals with it, but the commit has not been merged there yet.

Duy

I think the fix should go into compat/. See

http://git.661346.n2.nabble.com/PATCH-0-5-fix-deadlock-in-git-push-tp7653666p7653818.html

(sorry, gmane seems down).

-Peff

A previous change introduced a call to pthread_sigmask() in order to block SIGPIPE in a thread. Since there are no signal facilities on Windows that are similar to POSIX signals, just ignore the request to block the signal. In the particular case, the effect of blocking SIGPIPE on POSIX is that write() calls return EPIPE when the reader closes the pipe. This is how write() behaves on Windows.

---
 compat/mingw.h         | 1 +
 compat/win32/pthread.h | 5 +++++
 2 files changed, 6 insertions(+)

index a950ae2..0f272fd 100644
@@ -142,6 +142,7 @@ static inline int fcntl(int fd, int cmd, ...)
 #define sigemptyset(x) (void)0
 static inline int sigaddset(sigset_t *set, int signum)
 { return 0; }
+#define SIG_BLOCK 0
 #define SIG_UNBLOCK 0
 static inline int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)
 { return 0; }

index b6ed9e7..d336451 100644
@@ -104,4 +104,9 @@ static inline void *pthread_getspecific(pthread_key_t key)
 	return TlsGetValue(key);
 }
 
+static inline int pthread_sigmask(int how, const sigset_t *set, sigset_t *oset)
+{
+	return 0;
+}
+
 #endif /* PTHREAD_H */

2.7.0.118.g90056ae

Looks good to me based on our earlier discussion (but of course I have no platform to test it on).

-Peff