Re: Implementing a "Synchronous Channel" with dispatch
Re: Implementing a "Synchronous Channel" with dispatch
- Subject: Re: Implementing a "Synchronous Channel" with dispatch
- From: Dave Zarzycki <email@hidden>
- Date: Wed, 14 Sep 2011 12:39:42 -0700
On Sep 14, 2011, at 12:08 PM, Andreas Grosam wrote:
>
> On Sep 14, 2011, at 8:00 PM, Dave Zarzycki wrote:
>
>> Dispatch queues exist to solve both the synchronous and asynchronous producer/consumer pattern. If you want the producer to wait until the consumer is done, then use dispatch_sync() instead of dispatch_async():
>>
>> x = create_something();
>> dispatch_sync(consumer_q, ^{
>> do_something_with(x);
>> });
>> // do_something_with() is done
>>
>> That's it. Easy, huh? :-)
> Yes, sure :)
>
> But - unless I miss something - I can't use that - or better I can't use this *directly* with my consumer (see previous post). That is, when the consumer finishes processing one data buffer, it needs to keep its state - through being blocked in its "get_me_more_data" method.
That's fine. Your block can still get at your object's instance variables:
- (void)doSomething
{
x = create_something();
dispatch_sync(consumer_q, ^{
_prev_state_ivar = do_something_with(_prev_state_ivar, x);
});
// do_something_with() is done
}
> The consumer's state (it's a parser) is the function stack. So, I need an intermediate actor - which is capable to hand off one data object. This is some kind of queue.
A dispatch queue should work just fine.
davez
>
>>
>> A note about dispatch semaphores: While they are powerful, they are not meant to replace queues. They exist for two very specific problems: 1) Refactoring synchronous APIs on top of asynchronous APIs and
>
>> 2) managing finite resource pools.
> This (2) is actually what I'm trying to accomplish (well, a bit more - performance for example). Otherwise, I would just safe the 100Mbyte data download on my iPhone in memory ;)
>
> A synchronous queue, would have capacity zero -- which would block producers till a consumer takes the data. This is what I want. Otherwise, if I would asynchronously queue the NSData objects, somehow, NSURLConnection would flood a iPhone with almost 1Mbyte per sec, that is a few seconds before crash.
>
> So, unless the parser is capable to truly parse partial content, and can return and restart while it's state is kept somewhere else, I can't see how to make it "easy" in conjunction with a NSURLConnection :)
>
>
> So, the questions remains: would the use of a "Synchronous Queue" be effective enough? What are the consequences?
>
> Andreas
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden