All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Windows: only add a no-op pthread_sigmask() when needed
@ 2016-05-10 13:00 Johannes Schindelin
  2016-05-10 17:57 ` Junio C Hamano
  2016-05-11 15:10 ` [PATCH v2] " Johannes Schindelin
  0 siblings, 2 replies; 5+ messages in thread
From: Johannes Schindelin @ 2016-05-10 13:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Sixt

In f924b52 (Windows: add pthread_sigmask() that does nothing,
2016-05-01), we introduced a no-op for Windows. However, this breaks
building Git in Git for Windows' SDK because pthread_sigmask() is
already a no-op there, #define'd in the pthread_signal.h header in
/mingw64/x86_64-w64-mingw32/include/.

Let's guard the definition of pthread_sigmask() in #ifndef...#endif to
make the code compile both with modern MinGW-w64 as well as with the
previously common MinGW headers.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	This patch is obviously based on 'next' (because 'master' does not
	have the referenced commit yet).

Published-As: https://github.com/dscho/git/releases/tag/mingw-sigmask-v1
 compat/win32/pthread.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
index d336451..8df702c 100644
--- a/compat/win32/pthread.h
+++ b/compat/win32/pthread.h
@@ -104,9 +104,11 @@ static inline void *pthread_getspecific(pthread_key_t key)
 	return TlsGetValue(key);
 }
 
+#ifndef pthread_sigmask
 static inline int pthread_sigmask(int how, const sigset_t *set, sigset_t *oset)
 {
 	return 0;
 }
+#endif
 
 #endif /* PTHREAD_H */
-- 
2.8.2.463.g99156ee

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] Windows: only add a no-op pthread_sigmask() when needed
  2016-05-10 13:00 [PATCH] Windows: only add a no-op pthread_sigmask() when needed Johannes Schindelin
@ 2016-05-10 17:57 ` Junio C Hamano
  2016-05-11 15:06   ` Johannes Schindelin
  2016-05-11 15:10 ` [PATCH v2] " Johannes Schindelin
  1 sibling, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2016-05-10 17:57 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, Johannes Sixt

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> In f924b52 (Windows: add pthread_sigmask() that does nothing,
> 2016-05-01), we introduced a no-op for Windows. However, this breaks
> building Git in Git for Windows' SDK because pthread_sigmask() is
> already a no-op there, #define'd in the pthread_signal.h header in
> /mingw64/x86_64-w64-mingw32/include/.
>
> Let's guard the definition of pthread_sigmask() in #ifndef...#endif to
> make the code compile both with modern MinGW-w64 as well as with the
> previously common MinGW headers.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> 	This patch is obviously based on 'next' (because 'master' does not
> 	have the referenced commit yet).

One thing that makes me wonder is what would happen when
/mingw64/x86_64-w64-mingw32/include/pthread_signal.h changes its
mind and uses "static inline" instead of "#define".  How much
control does Git-for-Windows folks have over that header file?

Also, could you explain "However" part a bit?  Obviously in _some_
environment other than "Git for Windows' SDK", the previous patch
helped you compile.  And you need to #ifdef it out, because "Git for
Windows' SDK" already has its own support.  What is that other
environment that lacks the support (hence we need our own "static
inline") and is there a way to tell "Git for Windows' SDK" from that
other environment?

What I am trying to get at is:

 (1) If the answer is "we have total control", then I am perfectly
     fine with using "#ifdef pthread_sigmask" here.

 (2) If not, i.e. "they can change the implementation to 'static
     inline' themselves", then I do not think it is prudent to use
     "#ifndef pthread_sigmask" as the conditional here--using a
     symbol that lets you check for that "other" environment and
     doing "#ifdef THAT_OTHER_ONE_THAT_LACKS_SIGMASK" would be
     safer.

Also is https://lists.gnu.org/archive/html/bug-gnulib/2015-04/msg00068.html
relevant?  Does /mingw64/x86_64-w64-mingw32/include/ implement "macro only
without function"?

> Published-As: https://github.com/dscho/git/releases/tag/mingw-sigmask-v1
>  compat/win32/pthread.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
> index d336451..8df702c 100644
> --- a/compat/win32/pthread.h
> +++ b/compat/win32/pthread.h
> @@ -104,9 +104,11 @@ static inline void *pthread_getspecific(pthread_key_t key)
>  	return TlsGetValue(key);
>  }
>  
> +#ifndef pthread_sigmask
>  static inline int pthread_sigmask(int how, const sigset_t *set, sigset_t *oset)
>  {
>  	return 0;
>  }
> +#endif
>  
>  #endif /* PTHREAD_H */

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Windows: only add a no-op pthread_sigmask() when needed
  2016-05-10 17:57 ` Junio C Hamano
@ 2016-05-11 15:06   ` Johannes Schindelin
  2016-05-11 21:01     ` Junio C Hamano
  0 siblings, 1 reply; 5+ messages in thread
From: Johannes Schindelin @ 2016-05-11 15:06 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Sixt

Hi Junio,

On Tue, 10 May 2016, Junio C Hamano wrote:

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > In f924b52 (Windows: add pthread_sigmask() that does nothing,
> > 2016-05-01), we introduced a no-op for Windows. However, this breaks
> > building Git in Git for Windows' SDK because pthread_sigmask() is
> > already a no-op there, #define'd in the pthread_signal.h header in
> > /mingw64/x86_64-w64-mingw32/include/.
> >
> > Let's guard the definition of pthread_sigmask() in #ifndef...#endif to
> > make the code compile both with modern MinGW-w64 as well as with the
> > previously common MinGW headers.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > 	This patch is obviously based on 'next' (because 'master' does not
> > 	have the referenced commit yet).
> 
> One thing that makes me wonder is what would happen when
> /mingw64/x86_64-w64-mingw32/include/pthread_signal.h changes its
> mind and uses "static inline" instead of "#define".  How much
> control does Git-for-Windows folks have over that header file?

We have no control over this, it is defined by one of the MSYS2 packages.
(I think those headers come directly from the MinGW-w64 GCC project.)

I can think of two different ways to resolve this, would you please
indicate your preference?

1. fix the non-POSIX-ness:

	#ifdef pthread_sigmask
	#undef pthread_sigmask
	#endif

   or even shorter:

	#undef pthread_sigmask

2. just go with whatever MSYS2 provides:

	#ifndef __MINGW64_VERSION_MAJOR
	[... define the no-op ...]
	#endif

> Also, could you explain "However" part a bit?  Obviously in _some_
> environment other than "Git for Windows' SDK", the previous patch
> helped you compile.

Yes, Hannes uses his own MSys environment. (Which is different from
everything *I* have, I think, it's not even msysGit.)

> What I am trying to get at is:
> 
>  (1) If the answer is "we have total control", then I am perfectly
>      fine with using "#ifdef pthread_sigmask" here.
> 
>  (2) If not, i.e. "they can change the implementation to 'static
>      inline' themselves", then I do not think it is prudent to use
>      "#ifndef pthread_sigmask" as the conditional here--using a
>      symbol that lets you check for that "other" environment and
>      doing "#ifdef THAT_OTHER_ONE_THAT_LACKS_SIGMASK" would be
>      safer.

So I guess that you're preferring my 2. above. Going on that assumption, I
will send out another iteration.

> Also is
> https://lists.gnu.org/archive/html/bug-gnulib/2015-04/msg00068.html
> relevant?  Does /mingw64/x86_64-w64-mingw32/include/ implement "macro
> only without function"?

Yes, it has that problem. Do we care, really?

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH v2] Windows: only add a no-op pthread_sigmask() when needed
  2016-05-10 13:00 [PATCH] Windows: only add a no-op pthread_sigmask() when needed Johannes Schindelin
  2016-05-10 17:57 ` Junio C Hamano
@ 2016-05-11 15:10 ` Johannes Schindelin
  1 sibling, 0 replies; 5+ messages in thread
From: Johannes Schindelin @ 2016-05-11 15:10 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Sixt

In f924b52 (Windows: add pthread_sigmask() that does nothing,
2016-05-01), we introduced a no-op for Windows. However, this breaks
building Git in Git for Windows' SDK because pthread_sigmask() is
already a no-op there, #define'd in the pthread_signal.h header in
/mingw64/x86_64-w64-mingw32/include/.

Let's wrap the definition of pthread_sigmask() in a guard that skips
it when compiling with MinGW-w64' headers.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Published-As: https://github.com/dscho/git/releases/tag/mingw-sigmask-v2
 compat/win32/pthread.h | 2 ++
 1 file changed, 2 insertions(+)
Interdiff vs v1:

 diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
 index 8df702c..1c16408 100644
 --- a/compat/win32/pthread.h
 +++ b/compat/win32/pthread.h
 @@ -104,7 +104,7 @@ static inline void *pthread_getspecific(pthread_key_t key)
  	return TlsGetValue(key);
  }
  
 -#ifndef pthread_sigmask
 +#ifndef __MINGW64_VERSION_MAJOR
  static inline int pthread_sigmask(int how, const sigset_t *set, sigset_t *oset)
  {
  	return 0;


diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
index d336451..1c16408 100644
--- a/compat/win32/pthread.h
+++ b/compat/win32/pthread.h
@@ -104,9 +104,11 @@ static inline void *pthread_getspecific(pthread_key_t key)
 	return TlsGetValue(key);
 }
 
+#ifndef __MINGW64_VERSION_MAJOR
 static inline int pthread_sigmask(int how, const sigset_t *set, sigset_t *oset)
 {
 	return 0;
 }
+#endif
 
 #endif /* PTHREAD_H */
-- 
2.8.2.465.gb077790

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] Windows: only add a no-op pthread_sigmask() when needed
  2016-05-11 15:06   ` Johannes Schindelin
@ 2016-05-11 21:01     ` Junio C Hamano
  0 siblings, 0 replies; 5+ messages in thread
From: Junio C Hamano @ 2016-05-11 21:01 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, Johannes Sixt

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> So I guess that you're preferring my 2. above. Going on that assumption, I
> will send out another iteration.

OK.

>> Also is
>> https://lists.gnu.org/archive/html/bug-gnulib/2015-04/msg00068.html
>> relevant?  Does /mingw64/x86_64-w64-mingw32/include/ implement "macro
>> only without function"?
>
> Yes, it has that problem. Do we care, really?

Not really.  I was curious how actively this area is evolving;
knowing that would help me judge pros-and-cons between your 1 & 2
above.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-05-11 21:01 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-10 13:00 [PATCH] Windows: only add a no-op pthread_sigmask() when needed Johannes Schindelin
2016-05-10 17:57 ` Junio C Hamano
2016-05-11 15:06   ` Johannes Schindelin
2016-05-11 21:01     ` Junio C Hamano
2016-05-11 15:10 ` [PATCH v2] " Johannes Schindelin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.