Thanks Allen, you're exactly right. I'm charged with the task of finding
lots of nasties like that in our old code base where a number of things
were just hacked in down and dirty. Our embeded environment moved from
XINU on an SH2/SH3 with no mmu support and a BSD protocol stack we hacked
in ou
> 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
On Fri, 13 Oct 2000, J. Scott Kasten wrote:
> 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 wh
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
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
t
5 matches
Mail list logo
