Why is the socket function not freed after it calls a closed call?

Question

I have a server application that opens a socket and listens for a connection. In the application, I have a separate thread that creates a socket, binds it and calls the listen and accept functions on it.

When the application closes, I call closesocket on the created socket, then I wait until the socket stream closes. However, if a thread waits in an accept function, the thread never terminates.

I thought the accept function would return after calling cloasesocket. Is that the right thought? If so, why does the accept function not return? Is there any other way to get the accept function to return?

Answer 1

Do not call accept if select does not say so. In this case, accept will never be blocked.

Answer 2

Check out the man page ... http://linux.die.net/man/2/accept

accept() blocks on socket A, and when a new connection arrives, a new socket B is returned to connect the client. This often happens in a tight loop with fork () and exec () to send a new connection to the child process to handle the connection, while the parent returns to accept () to wait for another connection.

Are you trying to say that another thread in your program is closing socket A from the accept () call?

Answer 3

I saw a similar problem when the WSAStartup and WSACleanup calls were not balanced.

The program called WSACleanup before calling closesocket . And a thread trying to close a socket, like the one that receives, blocks. When I removed the “extra” WSACleanup things improved.

Elsewhere it says that the WSACleanup call WSACleanup release the accept call with an error, but I'm not sure if this is true ... And who knows what else is wrong if you do not agree with the function launching and clearing.