[Vm-dev] Re: [squeak-dev] Re: Socket clock rollover issues

[John M McIntosh]

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 at smalltalkconsulting.com>   Twitter:   
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================