Re: How do I use NSStream with dispatch queues?
Re: How do I use NSStream with dispatch queues?
- Subject: Re: How do I use NSStream with dispatch queues?
- From: Raffi Khatchadourian <email@hidden>
- Date: Mon, 19 Mar 2012 20:06:17 -0700
There's another method named -performSelectorOnThread, which lets you run code in an arbitrary loop.
Sent from my iPad 2
On Mar 19, 2012, at 7:55 PM, Mark Pauley <email@hidden> wrote:
> I don't think you've read what he wrote. He knows all about how to run stuff on the main runloop. He wants to avoid this for very good reasons. First of all, his current implementation completely avoids the main runloop as it should. All of the networking in NSURLConnection happens on a background thread. This is easy to verify with gdb.
>
> Jens: you'll have to find some way to bridge your gcd queues back to the runloop on which the protocol is invoked. I would recommend using a CFRunLoopSource that you message, using a queue as the method of message passing from your gcd code. There has got to be someone else who has solved this issue. Otherwise, I would recommend filing a feature radar for an API that will help out with this. Something that will somehow set the target queue of a given gcd queue to a queue that is run on a given runloop / mode. As far as I'm concerned, this seems doable via target queues, if there is some method of making a queue take action upon enqueuing a block. In this case, the side effect would have to be to wake up the runloop of the master queue when one of the slave queues gets work.
>
> Of course, I just pulled this out of my hat... someone may know if such a mechanism already exists.
>
> _Mark
>
> On Mar 19, 2012, at 7:10 PM, Raffi Khatchadourian wrote:
>
>> Have you considered the -performSelectorOnMainThread method?
>>
>> On Mar 19, 2012, at 11:59 AM, Jens Alfke wrote:
>>
>>> I want to fix the threading of some increasingly-complex network code I’m writing[1]. Currently it all ends up running on the internal NSURLConnection thread (ick!) because it’s invoked by an NSURLProtocol instance. I want to move it all to a dispatch queue. But I’m finding out that it’s hard to wean existing code off of runloop-based asynchrony.
>>>
>>> My current sticking point is NSStream. Even though my code is all HTTP-based, I have to use NSStream to be able to stream large HTTP bodies (using the NSURLRequest.HTTPBodyStream property.) And unlike NSURLConnection, NSStream doesn’t have a way to hook its delegate up to a dispatch queue, only to a runloop.
>>>
>>> Here I get really worried. It seems as though I’d have to use some kludge like borrowing the main thread’s runloop to schedule my stream delegate on. But this means I’m not independent of the main thread anymore, so my network code could get stuck if the UI is busy (and conversely I might hurt UI responsiveness if my delegate takes too long.) It also sounds like this approach is subject to some weird intermittent threading glitches, as described in a blog post by Jamie Pinkham[2].
>>>
>>> But the alternative ― not using dispatch queues ― still seems really primitive. I’d have to spawn my own NSThread, start up a runloop on it, implement a custom thread-safe queue to hold request objects of some sort, and write some CFRunLoop glue to twiddle a runloop source so I can wake up the thread when a request is posted. I did it once before in 2005 and it was surprisingly hard to get right.
>>>
>>> It really seemed like GCD had fixed all of this, but now it looks to me like GCD support is still kind of half-baked, even several years after it showed up in 10.6. Or am I missing something?
>>>
>>> ―Jens
>>>
>>> [1] https://github.com/couchbaselabs/TouchDB-iOS
>>> [2] http://jamiepinkham.com/post/4366476208/on-gcd-and-nsstreams
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Macnetworkprog mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Macnetworkprog mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden