cocos2d/cocos2d-x — pull request #7192 by kezhuw (2014-06-24 16:30:42+00:00)
Title: bugfix: condition variable sleep on unrelated mutex

In HttpClient::networkThread 's main loop:

```
// step 1: send http request if the requestQueue isn't empty
request = nullptr;

s_requestQueueMutex.lock();

//Get request task from queue

if (!s_requestQueue->empty())
{
request = s_requestQueue->at(0);
s_requestQueue->erase(0);
}

s_requestQueueMutex.unlock();

if (nullptr == request)
{
// Wait for http request tasks from main thread
std::unique_lock lk(s_SleepMutex);
s_SleepCondition.wait(lk);
continue;
}
```

After `s_requestQueueMutex.unlock();` and before ` s_SleepCondition.wait(lk);`, there are chances that requests send through `HttpClient::send`. Then network thread will block on `s_SleepCondition` while there are requests in `s_requestQueue`.

This pull request just fix it.

There are other race conditions in this module for now, eg:
* Between call sequences `HttpClient::destroyInstance()` and `HttpClient::getInstance()->send()`, there are chances `s_requestQueue` is not in `HttpClient::lazyInitThreadSemphore`. So that new network thread is not started, while old network thread is about to terminated.
* After `scheduler->performFunctionInCocosThread(CC_CALLBACK_0(HttpClient::dispatchResponseCallbacks, this));`, there is no guarantee that `this` is valid in `HttpClient::dispatchResponseCallbacks`.

The easiest way to suppress those is deleting public interface `HttpClient::destroyInstance`.

Also `s_cookieFilename` may not be thread-safe, it is depend on how `HttpClient::enableCookies` supposed to be called.