Did you try with the VM with the new semaphores?
not sure. The method below answers this question?
and without the new semaphores handling?
again, now sure.
In the two cases the primitives used looks different.
What should I look?
Could you also provide a size of the image?
it's a 53MB image but in RAM at the moment of the crash we don't know (we wanted to know but we didn't catched it in fraganti)
If the crash reproducible?
in development in OS X no it doesn't (same data).
in production, since we started the app with the StackVM, we are having uninterrupted uptime (so far and counting...)
VirtualMachine>>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 := true.
^ 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"]