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] |
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] |