Re: src/winsup/cygwin ChangeLog include/cygwin/sig ...

[Eric Blake <eblake at redhat dot com>]

On 10/27/2012 04:25 AM, Corinna Vinschen wrote:
> On Oct 26 12:52, Eric Blake wrote:
>> On 10/26/2012 12:29 PM, Corinna Vinschen wrote:
>>> If there's no reason to keep space, I would opt for this implementation:
>>>
>>> #ifdef __x86_64__
>>> #define NSIG    65      /* signal 0 implied */
>>> #else
>>> #define NSIG    33      /* signal 0 implied */
>>> #endif
>>>
>>> /* Real-Time signals per SUSv3.  RT_SIGMAX in limits.h has to agree. */
>>> #define SIGRTMIN 32
>>> #define SIGRTMAX (NSIG - 1)
>>>
>>> It's not dynamic, but it doesn't seem to make a lot of sense to make it
>>> dynamic.  Even in the 32 bit case, if we change the number of available
>>> RT signals it can also occur together with the ABI change, so an old
>>> application would still have the old number of RT signals, despite any
>>> effort to make the number dynamic.  Me thinks.
>>
>> Seems reasonable to me - if there is ever a new signal added, we'd also
> 
> I don't quite understand.  The joke here is that the above would NOT allow
> to add any further signal.  Ever.  Except for more RT signals in the 32
> bit case.  What am I missing?

If we ever add a new signal, it would be an ABI change - code compiled
against old cygwin.dll would call into the old ABI, where there are 32
or 64 total signsl with 1 or 33 RT signals and no access to the new
signal; new code would call into the new ABI where there are 64 total
signals (even on 32-bit cygwin) and the new signal has been carved out
appropriately.  That is, the cost of adding a new signal for 32-bit
cygwin is an ABI change, but if we do the ABI change, we can also do it
for 64-bit cygwin at the same time.

But I think this is theoretical - we are unlikely to add a new signal,
so go with the above definition without worrying about it.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature