Re: Can I create a thread with a runloop and a dispatch queue?
Re: Can I create a thread with a runloop and a dispatch queue?
- Subject: Re: Can I create a thread with a runloop and a dispatch queue?
- From: Kyle Sluder <email@hidden>
- Date: Thu, 03 Oct 2013 16:06:14 -0700
On Thu, Oct 3, 2013, at 01:00 PM, Jens Alfke wrote:
>
> On Oct 3, 2013, at 12:17 PM, Kyle Sluder <email@hidden> wrote:
>
> > What is adopting GCD going to get you if you aren't going to use GCD the
> > way it was intended?
>
> Could you be a bit friendlier here and cut me some slack? Of course I
> want to use GCD in the way it’s intended. I’m an experienced developer,
> I’ve been writing concurrent code for 15 years, I use GCD-type constructs
> all the time in Go. I have read the GCD documentation and I think I have
> a good handle on its principles.
I'm not trying to be snarky. I'm sorry if it came across that way.
>
> I want to be able to use GCD without breaking all of the non-GCD code in
> my project, until such time as I can replace all that code.
My point is that using GCD is not a win if you aren't actually going to
use it in a way that is compatible with its design, and that any bridge
you try to build between them is going to be complicated, fragile, and
have potentially well-hidden but catastrophic failure conditions
(exhausting the thread pool because a bunch of threads are blocked
waiting for your bridge to take care of business).
>
> Also, my project is a library, and I don’t want to put too many
> restrictions on how it’s used by the caller. For example, here’s one
> method that runs an async query:
> - (void) runAsync: (void (^)(CBLQueryEnumerator*))onComplete;
> When the query results are available, the onComplete block is called. The
> problem is, in what context should the block be called? Currently it’s
> scheduled on the same runloop as the original call. That works great for
> runloop-based clients. But if this method is called from a dispatch queue
> (except the main one) it won’t work. Do I have to have a second variant,
> like runAsync:onQueue:, that does the same thing except it invokes the
> block on a queue? That’s messy, and if runloops had queues it would be
> unnecessary.
Other people have addressed the dispatch_get_current_queue() problem.
Andy Matuschak has opined that the correct way to design an API that
accepts a block argument is to also accept a dispatch queue on which to
run that block. There are further points about cancellability embedded
in this discussion that I can't recall at the moment.
--Kyle Sluder
_______________________________________________
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