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).