[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