I've found the problem. This type of loop does not work:
do {
alarm(t);
read(fd);
if (EINT)
exception();
else
alarm(0);
} while (data);
There are some semantics here that differ from other *nix where this
works. The read() won't come out when the alarm comes, and the socket
will effectively become broken.
Instead, it appears that I needed to use select(), which probably would
have been better in the first place anyway.
Thanks to anyone that took the time to look at this.
-S-
> I'm working with test6 on an embedded
> QED MIPS arch in big endian mode. I
> have run into some bizarre socket problems that appear to affect both
> udp and tcp transport. Applications actively using sockets (examples,
> ftp, tftp, others...) will unexpectedly stop receiving data on the
> socket, even though data is present. The process will be forever
> sleeping on the read even though data is queued up. To illustrate my
> point, I've dug deep into the udp code (net/ipv4/udp.c) and the
> datagram core (net/core/datagram.c) researching the simple tftp
> example.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
