Socket: 10038 error {winSock bug: it may cause problems when closesocket is used for multiple errors}, 10038 closesocket

(Reprinted) socket: 10038 error {A winSock bug: it may cause problems when closesocket is used for multiple errors}, 10038 closesocket

In the past few days, I want to modify an open source code to develop a product.
The program was originally a single-Thread Network Program and needs to be modified to multiple threads. After the modification, there is always a problem. The recv function in the auxiliary thread always receives a datagram with a length of-1 after running for a while, the program runs incorrectly or even crashes.
Due to multithreading, I had to debug logs and find a strange problem. Both thread A and thread B use the socket function to generate A socket. two sockets with the same return value will be generated! That is to say, thread A and thread B can simultaneously obtain A socket with A socket value of 360. In this way, when thread A is using 360 for data receiving, and thread B connects to thread A, thread A naturally goes wrong.

This problem is really strange, because socket is not a COM component and can be shared directly in the thread. What is the problem, NO content related to this issue was found on MSDN and the Internet. An API error occurred! It is impossible.
I had to review the code and found that there are many such statements in the program:
If (mSocket! = INVALID_SOCKET)
{
Closesocket (mSocket );
}
Is there any problem with this sentence? It seems that there is no problem, but it is undeniable that a socket will be closed multiple times. In line with the principle of dead horse in the active horse doctor, modify each closesocket, set the socket value to INVALID_SOCKET, run the program, and solve the problem.

This problem is too ft. windows didn't even handle this fault tolerance. It is a good practice to make sense. socket is actually just an index value, when the system kernel is shut down, if it finds that it has been closed, do not perform any operation. Now it looks like a socket buffer pool in the kernel, and the program uses the count to manage the lifecycle. In this way, when a socket is closed multiple times and a socket is created and changed, the system may think that the socket is closed (because the count is less than or equal to 0 ). So the next allocation will re-allocate the index.

This problem occurs on the vista home edition. It is unknown that there are no problems on other platforms. We can see the benefits of paired encoding and the benefits of object-oriented encapsulation.