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 (Cocoa-dev@lists.apple.com)
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/zarzycki%40apple.com
> 
> This email sent to zarzy...@apple.com

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to