1 | | In Windows, the {{{pj_ioqueue_unregister()}}} in IOCP ioqueue backend does not close the socket, causing it to still appear in "netstat" and further it causes assertion about invalid handle in WSACleanup(). |
| 1 | The IOCP documentation says that application needs to call {{{CloseHandle()}}} to unregister the socket from the IOCP, and PJLIB does this in {{{ioqueue_winnt.c}}}. |
| 2 | |
| 3 | We assumed that a call to {{{CloseHandle()}}} should close the socket (just like {{{closesocket()}}}), since a socket should just be another handle in Windows NT. |
| 4 | |
| 5 | But turns out this is not the case. A call to {{{CloseHandle()}}} doesn't seem to close the socket, as the socket still appears in "netstat" output. Also further down it will cause "Invalid handle" exception to be raised in debug mode when {{{WSACleanup()}}} is called. |
| 6 | |
| 7 | Checking at MSDN documentation about {{{CloseHandle()}}} (see http://msdn.microsoft.com/en-us/library/ms724211(VS.85).aspx), actually it does suggest application to call both for socket, i.e. always follow {{{closesocket()}}} call with {{{CloseHandle()}}}. This is what it says: |
| 8 | |
| 9 | ''After closing a socket using the closesocket function, ensure that you release the socket by calling !CloseHandle. For more information, see [http://msdn.microsoft.com/en-us/library/ms738547(VS.85).aspx Socket Closure].'' |
| 10 | |
| 11 | But alas! From experimentation, turns out that calling {{{CloseHandle()}}} after {{{closesocket()}}} will raise "Invalid handle" exception in debug mode. This was tested on WinXP SP2. |
| 12 | |