On Oct 7, 2013, at 11:16 , Norbert Hartl <norbert@hartl.name> wrote:

As I need an image that runs longer than 24 hours I'm looking at some stuff and wonder. Can anybody explain me the rationale for a code like this

maxExternalSemaphores: aSize 
"This method should never be called as result of normal program
execution. If it is however, handle it differently:
- In development, signal an error to promt user to set a bigger size
at startup immediately.
- In production, accept the cost of potentially unhandled interrupts,
but log the action for later review.
See comment in maxExternalObjectsSilently: why this behaviour is
desirable, "
"Can't find a place where development/production is decided.
Suggest Smalltalk image inProduction, but use an overridable temp
meanwhile. "
| inProduction |
self maxExternalSemaphores
ifNil: [^ 0].
inProduction := false.
^ inProduction
ifTrue: [self maxExternalSemaphoresSilently: aSize.
self crTrace: 'WARNING: Had to increase size of semaphore signal handling table due to many external objects concurrently in use';
crTrace: 'You should increase this size at startup using #maxExternalObjectsSilently:';
crTrace: 'Current table size: ' , self maxExternalSemaphores printString]
ifFalse: ["Smalltalk image"
self error: 'Not enough space for external objects, set a larger size at startup!'
"Smalltalk image"]

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.

Cheers.
Henrik