Re: using grand central dispatch with c++ for inter-thread communication
Re: using grand central dispatch with c++ for inter-thread communication
- Subject: Re: using grand central dispatch with c++ for inter-thread communication
- From: Kevin Van Vechten <email@hidden>
- Date: Wed, 21 Apr 2010 11:26:43 -0700
Hi Joel,
Good article. You describe a perfectly good technique for what you're trying to accomplish — inter-thread communication between existing (well known) threads running CFRunLoop — and there are plenty of instances where this is exactly the right thing to do, especially when bridging existing technologies together.
However, this isn't exactly the "GCD" way of doing things. The true GCD way is to let the dispatch queue *be* the run loop, enqueue work asynchronously via dispatch_async, and have the system implicitly manage the threads for you. That's where the power and performance of GCD really shine.
But don't get me wrong. I'm certainly happy to see you chose to write up an article describing the syntactic convenience of blocks, CFRunLoopPerformBlock and dispatch semaphores. Thanks!
Kevin
On Apr 21, 2010, at 8:45 AM, Joel Reymont wrote:
> On Apr 21, 2010, at 4:14 PM, Brian Bechtel wrote:
>
>> Wouldn't pointing directly to the article be more efficient?
>>
>> <http://wagerlabs.com/grand-central-dispatch-c-and-inter-thread-com>
>
> A bit of context is probably due...
>
> I wrote a user land USB driver and packaged it in a framework. The framework starts the driver in a new thread upon initialization. I needed the separate thread and needed a way to talk to it.
>
> I explored Mach ports but these turned out to be too painful. Grand Central Dispatch, on the other hand, turned out to be the answer to my prayers. I can shuffle code and data back with no problems whatsoever.
>
> As a bonus, my API calls are queued and serialized for me so I don't need to lock portions of the driver for concurrent access.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden