Am 07.10.2013 um 11:28 schrieb Henrik Johansen <henrik.s.johansen@veloxit.no>:
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.
Agreed. But didn't work in my case because it needed roughly 20 hours and an instable remote backend to trigger the problem. And somehow I forgot to install my logger as Transcript so there is no warning message. I saw only dead images in the morning. This not satisfactory but on the other hand this type of problems are hard to solve anyway. My feeling tells me there is more to discover. Sockets resources get unregistered at finalization time but this didn't work either. I would have said that the unlikely situation that no garbage collection ran could be the case. But it can't because in ExternalSemaphoreTable>>#freedSlotsIn:ratherThanIncreaseSizeTo: there is explicit garbage collection.
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.
Ah, I didn't know about the risk of loosing signals while resizing the table. Thanks for that. Don't get me wrong I wasn't proposing to set inProduction in effect. I don't think that automatically growing resource management is a proper way to design a system. There is always a range of resources you need for your use case. Not setting an upper bound for this just covers leaking behavior. Norbert