On Oct 7, 2013, at 11:28 AM, Henrik Johansen <henrik.s.johan...@veloxit.no> wrote:
> > On Oct 7, 2013, at 11:16 , Norbert Hartl <norb...@hartl.name> wrote: >> >> I have reported this once but got no feedback so I like to have a few >> opinions. >> >> The report is here: https://pharo.fogbugz.com/f/cases/10839/ >> >> Norbert > > The rationale is that inProduction would be some global setting, not yet in > place when the code was written… > Excessive simultaneous Semaphore usage is something that should be caught > during development, in which case it's better to get an active notification, > than having it logged somewhere. > If I've understood correctly, it's moot on newer Pharo VM's, where there's no > limit on the semtable size, but for legacy code a startup item setting size > using maxExternalObjectsSilently: (as suggested in the Warning text), is > still a more proper fix than setting inProduction to true and crossing your > fingers hoping no signals will be lost during table growth. > The problem with this "set this secret flag in deployment" is that nobody knows it. *And* I am convinced that *everything* that is different in development to deployment will come back and hurt you *hart* when you least expect it. Marcus
signature.asc
Description: Message signed with OpenPGP using GPGMail
