incorect waiting for packets on UDP connections.

[ET]

Preconditions: Have an UDP server. Transform the socket into a handle. call hWaitForInput. When it returns True. call recv to read the datagram.

Expected result: it will wait for a package with the hWaitForInput. when the package arrives (withing the timeout). it will read it in the buffer. (this is how it works in HUGS).

Actual result: hWaitForInput consumes the package (I think). recv will block until the next package arrives.

[simonmar]

This is not a bug - Handles have buffers, so when you use hWaitForInput, the input is read into the buffer. The recv function doesn't read from the Handle, so it doesn't see the data in the buffer. The rule of thumb is that if you turn a socket into a Handle, you should use the Handle operations for reading and writing from then on.

[ET]

The problem still remains. The semantic of glibc read on an UDP socket is: if you read only part of a package the rest will be lost. There is no way, unless you hook it to the buffered reading buffer some how, to specify the number of bytes that you want to attempt to read from the handle. So let's see: If I have an udp socket as a handle. I have space in the buffering system just for a char. I receive a datagram 64KB in length(let's not go jumbo and say that I receive a 4GB one (on ipv6 it is possible)). How can I configure the system so that hWaitForInput will not lose any data?

[simonmar]

You can't use hWaitForInput, for the reasons that you state. You can still use threadWaitRead, or the lower-level functions from the unix package.