This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 10/26/2012 10:05 AM, Corinna Vinschen wrote:
>> Oh btw.
>>
>> Linux defines all signals beyond SIGRTMIN as RT signals.  Do we follow
>> the lead or is there some good reason to restrict the number of RT
>> signals to keep space for later extensions?

I don't think it is very likely for new signals to appear anywhere (for
the same reason it's hard for us to swap from 32 to 64 - most
implementations are now already maxed at 64 and adding a new signal
would be an ABI change).  So we can probably safely follow suit.  Or we
can limit to just 8 RT signals, as the minimum guaranteed by POSIX, and
leave trailing bits for possible extensions.  Oh, and POSIX says
SIGRTMAX need not be a constant, so if we make it a function call _now_
(such as something based on sysconf(_SC_RTSIG_MAX)), then we can always
have that return a smaller value later - applications that use RT
signals already have to be prepared for the set of RT signals to be
dynamically sized according to POSIX.

> 
> I see one signal in Linux which we don't have yet, SIGSTKFLT.  Is it
> worth to keep space for that?

It's non-standard, and I have no idea under what conditions Linux
generates it for us to even emulate it.

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

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]