[gambit-list] Strange Networking Bug on MinGW (LONG)

François Magnan francois.magnan at licef.ca
Mon Feb 11 10:05:16 EST 2008


Hi Christian,

Thank you for your help. The "Content-Length" header is not the issue  
here because the faulty code does byte-by-byte IO (read-u8, write-u8)  
so I know exactly how many bytes I output and there is no encoding/ 
decoding taking place without my knowledge. In fact it works very well  
if I disable the concurrent calls to open-tcp-client. It also always  
work perfectly on MacOSX so I doubt there is an enconding issue.

About your second thought, the clock resolution problem on OSX is not  
the problem since it works on OSX like I said above.

For me, it looks like read-u8 and write-u8 in MinGW are somehow  
blocked when there is too much parallel network activity. I could not  
drill it down to a simpler case that the one I sent.

In the meantime, I will avoid using read-u8 and write-u8 on WinXP.

Thank you,
Francois Magnan


On 10-Feb-08, at 6:17 PM, Christian Jaeger wrote:

> François Magnan wrote:
>> What could lead to this huge difference between a sequence of read- 
>> u8 and read-line on WinXP???
>
> Just an idea (I don't run windows and am too tired to study the code  
> in detail): you might be miscalculating the reply length, compared  
> to what's actually being sent, since possibly you/the runtime might  
> be decoding/encoding utf8 twice or something, and then the  
> individual requests might only be "finished" when some part timeouts  
> (the browser might be closing the connection after some timeout).  
> I'd check what goes over the wire (and when) with some tool that can  
> do that (something like GNU/Linux' strace or tcpdump).




More information about the Gambit-list mailing list