elee6i5@jetson.uh.edu (10/30/90)
I am trying to set up a system wherein a client tries to send many files for a remote server's consumption. The way I go about is - open a new socket - connect - fork a child to send data The parent contiues this in a loop. The children after sending the data close their sockets. But the parent should also close the sockets on which data transfer has been completed in order to clear up the system table entry. I tried doing it this way. The parent traps SIG_CLD and the handler identifies the exiting child and closes the corresponding socket. Now the question is how to handle interruped system call "connect" When connect is retried (called again) if it returns with EINTR, it fails again with EISCONN (socket already connected or previous connect attempt not completed ; whatever it means) Can some explain this and suggest (email) how to handle interrupted call to connect ? Thanks in advance, .sundar elee6i5@jetson.uh.edu
chris@mimsy.umd.edu (Chris Torek) (10/30/90)
In article <7380.272cbb05@jetson.uh.edu> elee6i5@jetson.uh.edu writes: >Now the question is how to handle interruped system call "connect" I will answer this first because this one is easy. Just call connect again. Any decent kernel (possibly not including some distributed by certain major manufacturers) will handle this correctly. (Another possibility is to use nonblocking connects, but this gets hairy.) None of this is necessary, though: >I am trying to set up a system wherein a client tries to send many files >for a remote server's consumption. The way I go about is > - open a new socket > - connect > - fork a child to send data > The parent contiues this in a loop. The children after sending the > data close their sockets. > >But the parent should also close the sockets on which data transfer has been >completed in order to clear up the system table entry. All you need do is close the socket in the parent immediately after forking. Closing a socket, like closing a pipe, has no effect unless you have the last instance of the descriptor. In this case, the child has one also. >When connect is retried (called again) if it returns with EINTR, >it fails again with EISCONN (socket already connected or previous >connect attempt not completed ; whatever it means) You have an indecent or defective kernel (probably based on the 4.2BSD implementation rather than one of the more reasonable BSD releases). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris