[Pharo-dev] external semaphores…again

Marcus Denker marcus.denker at inria.fr
Mon Oct 7 05:34:01 EDT 2013

On Oct 7, 2013, at 11:28 AM, Henrik Johansen <henrik.s.johansen at veloxit.no> wrote:

> On Oct 7, 2013, at 11:16 , Norbert Hartl <norbert at 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131007/0abea4fc/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131007/0abea4fc/attachment.asc>

More information about the Pharo-dev mailing list