On 5-May-09, at 7:09 PM, Andreas Raab wrote:
Yes. I don't think that's the problem. Right now my theory is that we're indeed overflowing the VMs semaphore buffer because a Python callout may take a long, long time. I think what happens then might be that over the period of time the (few) sockets generate multiple semaphore signals which overflows the VMs buffer and then there is no room left in the buffer when the callback executes.
Well given the if (foo->semaphoresUseBufferA) { if (foo->semaphoresToSignalCountA < SemaphoresToSignalSize) { foo->semaphoresToSignalCountA += 1; foo->semaphoresToSignalA[foo->semaphoresToSignalCountA] = index; } } else { if (foo->semaphoresToSignalCountB < SemaphoresToSignalSize) { foo->semaphoresToSignalCountB += 1; foo->semaphoresToSignalB[foo->semaphoresToSignalCountB] = index; } }
You could just code up the else to print diagnostic data when the foo-
semaphoresToSignalCountA IS = to SemaphoresToSignalSize
Also in checkForInterrupts at
foo->semaphoresUseBufferA = !foo->semaphoresUseBufferA;
is there exposure on multi-cpu machines for semaphoresUseBufferA to be NOTed as it's evaluating "if (foo->semaphoresUseBufferA)" Oh likely there is... maybe we need a volatile on the semaphoresUseBufferA ? But I'm not sure that will work since this the traditional race condition on a shared memory location between two cpus. '
If that's true then I should be able to recreate the problem by calling an OS-level sleep() function via FFI (i.e., block the main interpreter loop) while performing heavy network activity and see if that overflows the VMs buffer.
And if that's indeed the case then I think there are two actions to take: One is to fix the Windows sockets code to not do that ;-) (i.e., not signal an already signaled semaphore a gazillion times) but also to keep track of the number of signals on a particular semaphore instead of keeping an entry in the buffer each time the semaphore is signaled (which would completely solve this type of problem in general).
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================