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

Christian Franke Christian.Franke@t-online.de
Tue Nov 5 11:37:31 GMT 2024


Corinna Vinschen wrote:
> 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.

A closer look might suggests that there are no use cases for packages in 
the Cygwin distro:

I did a quick check unpacking all *.dll *.exe *.so (with --backup=t) 
files (~20GiB) from all x86_64/release/**tar* files from a local Cygwin 
mirror. An 'objdump -p' on each file (total 24Gib) lists 
pthread_sigqueue only for the various cygwin1.dll releases. Even the 
stress-ng package I maintain isn't affected because the related stress 
test is guarded with #ifndef __CYGWIN__.

-- 
Regards,
Christian



More information about the Cygwin-patches mailing list