On Mon, Feb 22, 2010 at 9:42 PM, Garrett D'Amore <gdamore at sun.com> wrote: > On 02/22/10 12:30 PM, Jason King wrote: >> >> On Mon, Feb 22, 2010 at 2:11 PM, Garrett D'Amore<gdamore at sun.com> wrote: >> >>> >>> On 02/22/10 12:00 PM, John Plocher wrote: >>> >>>> >>>> Given Roger's comment that 64 and beyone "breaks binary compatibility" >>>> and should only be done on a major release boundry, isn't *this* the >>>> exact right time to do so? The Solaris10 to OpenSolaris Enterprise >>>> change IMO *is* such a major release point. There won't be such an >>>> opportunity again for decades... >>>> >>>> >>> >>> OpenSolaris still retains most of the binary compatibility with Solaris >>> Nevada. Unless there is a really compelling reason, I'd be loathe to >>> support any change which breaks existing S10 binaries. >>> >>> The ARCs are still (I believe) operating on the assumption that Solaris >>> Next >>> and/or OpenSolaris represent a "pseudo major" release boundary. This >>> means >>> that we can allow some interface breakage where it makes sense, but we >>> are >>> still expected to try to ensure that most normal applications that work >>> on >>> Solaris 10 and earlier will continue to function on the next release. >>> >>> We actually have more flexibility, IMO, in administrative interfaces such >>> as >>> dladm, packaging, etc. >>> >> >> Isn't this what S10 containers are for? Could this be done in a way >> that S10 containers still run things correctly, while 'new' stuff gets >> the advantage of having the upper limit? As John said, the >> opportunity probably won't arise to revisit this again for a very >> long time, and as a customer who was burned for a very long time by >> the 256 fd limit for stdio (until a rather clever workaround was >> created), I'd be loathe to revisit similar limitations if it appears >> we are starting to approach them. >> > > You should not have to use a Container to run *any* S10 application, which > is what such a change would effectively cause. It would create huge > heartache and pain for everyone involved, and create a *serious* impediment > for moving customers to using OpenSolaris. > > If there was a really compelling argument, I can see investigating a way for > applications to be built with a special flag that enables this (not even > sure if that is possible) ala the 64-bit file offset flags, but I haven't > heard any compelling evidence that more than 32 such signals is actually > necessary for any real world applications.
The compelling reason is to use more than 32 workers (i.e. processors, threads or processes depending on context and toolkit) in applications which are based on IBM and VXWORKS toolkits. Realtime signals are often used for fast IPC between workers which are either threads or processes and the number of workers is limited by the number of realtime signals. Irek
