Optimize input queue processing in SRProxyConnect.

[nlutsenko]

Purely to tackle the theory described in #421 (comment)

[erikprice]

This looks good, @nlutsenko. Thanks for submitting this.

We can't reproduce the bug that this fixes, but we've seen it in the field. We are still using a fork of SocketRocket, if you remember. I'll apply this commit to our fork and it will go out in our next App Store release, and we'll let you know if we see a drop in crash reports for this problem.

[richardjrossiii]

What does the stack trace look like when -dequeueInput is invoked? Are there still ivar references to the SRProxyConnect around that aren't strong at that time (that could then cause a crash in the method that invokes dequeueInput)?

Honestly, I think the proper solution here is to either

• A: Hold a strong reference to self for the duration of deuqueInput (and potentially, the calling function).
• B: Ensure that the ProxyConnect object is not deallocated in the completion handler.

Having this strange scenario where you potentially cannot use any of the variables in self after calling _proxyProcessHTTPResponseWithData seems dangerous, and likely to break again in the future.

[erikprice]

@richardjrossiii said

What does the stack trace look like when -dequeueInput is invoked?

You can see the stack trace from two separate apps that have encountered this problem in #421.

Are there still ivar references to the SRProxyConnect around that aren't strong at that time (that could then cause a crash in the method that invokes dequeueInput)?

I'm not sure if there is an ivar reference to the SRProxyConnect within the SocketRocket project, but it does seem possible that the SRProxyConnect object is still set as the delegate of a NSStream object at that time, and this property is listed as having assign semantics in Apple's header file.

Does that help with your assessment?

[nlutsenko]

Per our discussion - I ended up just moving the cleanup for proxy connect to the work queue, instead of creating an autoreleasing local scope variable. Biggest reason - it's disconnected and most of the calls are in a separate method.

[richardjrossiii]

#shipit