When using TSocketClient in a Cocoa client and correctly managing the memory:
(maybe this should be fixed in the cocoa example, memory management is erroneous there)
After successfully releasing the object with the code above. One gets a EXC_BAD_ACCESS signal because the runloop send a responseToSelector: message to our object. With the selector stream:handleEvent:
This all leads to TSocketClient which opens two NSStream objects and delegates it self to both, afterwards both Streams are scheduled in the runloop, which should actually notify the delegate when something happens to the stream like data is available, this obviously results in the runloop asking TSocketClient for previously described selector. However this mechanism is not used, the TNSStreamTransport class is subclassed and responsible for read/write.
So why are the Streams schedules in the run loop in the first place?
Why are the streams not closed and released when the object gets deallocated?
I could fix this behavior by implementing a dealloc method in TSocketClient and making the Streams member variables
However I still don't know if that is the right way.
The bug is still present in 0.9 I attached a TSocketClient.m that fixes this Problem, the TSocketClient also keeps track of the streams and upon deallocation it closes the stream, removes it from the runloop and releases it (if arc is not enabled). This also removes a bug in non-arc environment that where the streams have a retaincount of +1 after deallocation such that the bug described here won't occur and the streams leak memory