[PATCH v2] Cygwin: Change pthread_sigqueue() to accept thread id

[Corinna Vinschen]

On Nov  4 15:34, Corinna Vinschen wrote:
> On Nov  4 12:50, Christian Franke wrote:
> > Corinna Vinschen wrote:
> > > ...
> > > > - Invent a #define that allows to use the old function.
> > > We don't need this.  We only want backward compat to keep existing
> > > executables running.  So we need The old and wrong pthread_sigqueue only
> > > as exported symbol.  On recompiling the affected project, the bug
> > > hopefully shows up and can be easily fixed.
> > 
> > Providing such a feature (only) for a few upcoming Cygwin releases would
> > allow maintainers (e.g. me maintaining stress-ng) to easily provide packages
> > which are backward compatible with still available [prev] versions of the
> > DLL.
> 
> We never did that yet.  Going forward, we try to maintain backward
> compatibility for new versions of Cygwin to existing executables, but we
> never promised or maintained backward compatibility for newly built
> executables to old versions of Cygwin.  That's setting an uncomfortable
> new precedent.
> 
> *Iff* we do this, then it should be least intrusive for the header,
> i. e., add a new entry point and use that in the backward compat case,
> kind of like this:
> 
> -------------------------------------------------------------
> 
> int pthread_sigqueue (pthread_t, int, const union sigval)
> 
> #ifdef _CYGWIN_USE_BUGGY_PTHREAD_SIGQUEUE
> 
> // TODO: Add some comment explaining this hack :-)
> int __pthread_sigqueue_buggy (pthread_t *, int, const union sigval)
>   __attribute__((__warning__("Using old version of pthread_sigqueue()")))
>   ;
> #define pthread_sigqueue(a,b,c)	__pthread_sigqueue_buggy ((a),(b),(c))
> 
> #endif
> -------------------------------------------------------------

I guess if it's only part of the 3.5 backport, it's ok.


Corinna