CCHttpClient when to destroy instance ?

cocos2d-x C++
#1

Hi,

Been playing with CCHttpClient, and got one doubt, when should one actually destroy the instance by invoking static method destroyInstance() ?
The static method getInstance() returns a new instance in case there’s none yet, otherwise it will return the existing instance, so that allows to:

A) invoking getInstance() in every CCScene and invoking destroyInstance() in every CCScene destruction/exit.
B) invoking getInstance() in every CCScene and invoking destroyInstance() only once at AppDelegate destruction/exit.

With scenario A, I have a problem. I’m using scene transitions and since original scene only exits after new is initializated, it will call destroyInstance() after new scene is initialized.
And since it’s a shared object, that will conflict with possible ongoing HttpRequest I already have in new scene after init().
I guess I could put a safe delay before creating HttpRequest in init() method to avoid this.

With scenario B, I’ll get loads of memory leak in debug output.

Advices ?

#2

Also worth mentioning that, at least in win32, I get in either scenarios above the following first-chance exceptions (thread related I guess):

First-chance exception at 0x7534b9bc in XXXXXX.exe: Microsoft C++ exception: ptw32_exception_exit at memory location 0x044ff84c..
First-chance exception at 0x7534b9bc in XXXXXX.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
#3

I think the HTTP instance should be shared between scenes and just initialize once when app starts and destroy when app ends

#4

Yes, now I have it like this:
It only initializes it once, when ever I run getInstance() the first time.
And destroy it when the app ends, at AppDelegate destructor.

Still get VC*+ ptw32 warnings…
<pre>
cocos2d: cocos2d-2.0-x-2.0.4
First-chance exception at 0x769eb727 in XXXX.exe: Microsoft C*+ exception: ptw32_exception_exit at memory location 0x0721f868…
First-chance exception at 0x769eb727 in XXXX.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000…

and leaks with CRTDBG\_MAP\_ALLOC… 
Detected memory leaks!

Dumping objects ->
{4504} normal block at 0x00756FF0, 8 bytes long.
 Data: <  u  nu > D8 FA 75 00 B8 6E 75 00 
{4503} normal block at 0x00756FB0, 4 bytes long.
 Data: <    > 00 00 00 00
(...)

But I’ll worry with that later :slight_smile: