On 11.10.2011 14:17, Henrik Sperre Johansen wrote:
On 11.10.2011 01:00, John Toohey wrote:
Henrik,
Could you explain this in a little more detail for me? Are you saying
the socket timeout is really a semaphore problem?
Yes, in that Sockets block on Semaphores registered in the vm, which
are then signalled from the external plugin.
The number of objects for which this signalling is done does not grow
automatically, see:
http://code.google.com/p/pharo/issues/detail?id=4505
for the discussion/rationale behind now raising an error when there's
no free space anymore, instead of silently losing signals.
The methods (with comments) in image resulting from this issue, and
interesting to read in this context is:
VirtualMachine >> #maxExternalSemaphores:
- you can change inProduction to true, and it will no longer crash,
but write you a warning that you might be losing signals due to too
little default space.
ExternalSemaphoreTable >> #collectionBasedOn:withRoomFor: and
#freedSlotsIn:ratherThanIncreaseSizeTo:
- comments should hopefully be useful
Cheers,
Henry
Reading it over, I see the temporary needToGrow in #freedSlotsIn: ... is
misnamed.
It should be freedSlots.
Cheers,
Henry
