> > 2.2.5) and things worked just fine. I brought it to some linux(redhat 4.1
> > kernel 2.0.29,libc 5.3.*) and weird things happen:
>
> libc 5.3.* is a development version. You should install one of the
> recent 5.4.* versions to eliminate that as a possible source of error.
yep. But libc 5.3.12 is the library shipped with R.H. 4.1. I guess I will
upgrade it anyway. thanks.
> > while(1)
> > {
> > close(sock_a);
>
> The first time that you get here, sock_a will have a random value, so
> you don't want to close it here. You should close it in the parent
> process after the fork().
hmm. But I don't have any other descriptors opened. (which may've been
randomly closed). And following the man page, if I don't have any opened
f-descriptors, close would return -1 and EBADF.
However, actually this close(sock_a) thing was the source of trouble, when
I removed it. (I close the same descriptor in process_connection()
function, called by child), things started working.. hmm. looks like the
problem with libc, I guess.
> > while(waitpid(-1, NULL, (int) NULL) > 0);
>
> You should pass WNOHANG as the third argument to waitpid(), otherwise
> this loop won't terminate.
yes I see. By the way, I played with my code foralittle, and killed it
while it was transforming data, when i ran it again, it couldn't bind to
the same port, i tried netstat, and here's what I got
tcp 1 45761 192.168.230.4:2000 192.168.5.4:1146 LAST_ACK
^^^^^ machine were server runs.
Looks like I broke the connection, and kernel still waits for last_ack
from remote. Is there way to flush such things?
> Neither of these seem likely to cause accept() to fail to accept a
> connection.
yeah.
> If I fix the above problems, it runs fine for me.
>
yep. Here also. and it worked on BSD in the old fashion as well.. strange.
