in reply to Re^2: Handling sockets in a server
in thread Handling sockets in a server

close on a socket could fail if the file descriptor has already been reaped [EBADF]. [EINTR] is also possible.

close is different from shutdown because close only cleans up the file descriptor in the current process, but shutdown will terminate the connection for all processes using it.

That is to say, if you fork a child process that has an open socket, closing it within either process will free the file descriptor associated with that socket, within that process, but the other process will be free to continue using it's copy of the file descriptor and the socket.

However, shutdown will terminate the connection for all processes that have a file descriptor associated with it. The file descriptor will remain after shutdown until they are explicitly closed or otherwise GC'd.

Not having a real fork available, I'll leave questions 3 & 4 to others :)

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^4: Handling sockets in a server
by skerr1 (Sexton) on Oct 21, 2005 at 18:23 UTC

    Thanks for the information. This was helpful. Can you tell me though what is the difference in return for closing the socket as apposed to the socket connection? What value am I getting out of closing each?

    close($new_sock); # Closes connection, I think your statement on return values applies to this close

    But what about

    close($sock); # What value am I getting out of checking the close of this, the actual socket, not a connection?

    Still waiting for 3 and 4 :)

    Shannon Kerr
[reply]
[d/l]
[select]

      I would think that either error return was equally valid from either.

    • In the case of EBADF, you probably don't care--you wanted it closed and it is--but it could be a useful indication of something wrong, a timing or logic error with your application. A warning to stderr or logfile might prove useful.
    • In the case of EINTR, it would mean that the process of clean up was interupted by an external signal, and therefore incomplete. The proper response would be to issue the close again, I think.
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      Hopefully someone can answer questions 3 and 4. Here they are again. I didn't copy my example code but it is in the orginial post. Thanks

      3. If the child process is executing a command like system("echo Hello");, I need to reap child processes before closing the forked child process so as not to leave "zombies" right? Or is my handling that via capturing the CHLD signal ($SIG{'CHLD'} = 'IGNORE';) before I even start up the socket sufficient? I wasn't sure I needed to do one of these:

      while ( my $child_process = waitpid(-1,WNOHANG) > 0 ) {
}

      [download]

      before I close the child each time.

      4. In Perl 5.6.1, after each accepted connection do I need to reset STDERR and STDOUT that I set prior creating the socket? Previously in Perl 5.005_02 I was having to reset these with each new connection. If that's the same, can someone tell me why?

      Shannon Kerr
[reply]
[d/l]
[select]

        Is there anyone that can help out with questions 3 and 4 in the original post of this thread 501889. Thanks!

        Shannon Kerr
[reply]

In Section Seekers of Perl Wisdom