Question

我有一个使用TCP（Winsock API）和HTTP（WININET API）套接字的应用程序。这是一个多线程应用程序，我有一个案例，当网络出现故障时，我调用一个重新连接线程（有一个while循环，但是睡眠几秒钟，每个用于tcp重新连接和http重新连接 - 基本上尝试套接字连接）。当tcp重新连接线程＆amp; http重新连接线程在一段时间后运行tcp重新连接线程到达此行：

TCP重新连接线程：

    DWORD WINAPI MyThreadProc ( LPVOID lParam )
    {
       printf ( "In MyThreadProc" ) ;
       // Code
       return 1 ;
    }

    hSampleHandle = CreateThread ( 0 , 0 (LPTHREAD_START_ROUTINE)MyThreadProc, this , 0 , &threadId ) ;

HTTP重新连接线程：

     DWORD WINAPI MyHttpThreadProc ( LPVOID lParam )
     {
       printf ( "In HTTP Reconnect" ) ;
       // Code
       return 1 ;
     }

     hHttpReq = CreateThread ( 0 , 0 , MyHttpThreadProc , this , 0 , &ThreadId ) ;

我检查了hSampleHandle的返回值，它也不是NULL我也得到了一个threadId。但是MyThreadProc没有被调用。然后我做WaitForSingleObject超时。我真的想知道这种行为的原因是什么？

更新： 1）注释掉MyHttpThreadProc中的代码后，我无法重现该错误。所以很明显在winsock和amp;之间共享一些资源。 wininet实现导致这种奇怪的行为。

2）我尝试冻结HTTP重新连接线程（来自Visual Studio 2012中的ThreadWindow），并且TCP重新连接线程工作正常。这导致了以下探测：

P.S：1）在应用程序级别上，这两者之间没有共享资源。

2）我怀疑死锁并继续在windbg（用户模式死锁）中进行调试，这显示了9个关键部分，但所有9个部分的lockcount值都没有被锁定。

3）我的另一个嫌疑人是使用WINSOCK＆amp; WININET在一起。我知道他们都使用mswsock.dll，它可能是一个导致内核死锁的加载器锁吗？在发行！kdexts.locks我面临一些错误，所以我没有深入研究。

4）这是否属于线程冻结类别？有人可以解释这种行为。

5）这个http://www.cpptalk.net/threadproc-does-not-run-when-createthread-is-called-within-vt7735.html在这里没用，因为我不使用单独的dll。

Answer 1

到目前为止似乎是Http线程实现中的一个挂起（当单独运行时）Wininet dll加载导致线程挂起/冻结。如果http中的挂起被修复并且模拟了类似的行为，则将重新打开该问题。

尽管CreateThread成功，但不会调用c ++ ThreadProc

1 个答案: