[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.

	Marcus


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