Swift GCD ... command line tool?

Question

pnm OP

Created Apr ’16

Replies 3

Boosts 0

Views 2.9k

Participants 2

Hello,

I'm trying to use Swift and GCD - to build a command line tool that can exploit concurrency and parallelism.

To get around the lack of a run loop, I've followed a helpful thread on StackOF - to use CFRunLoop.

So far, so good.

However, if tasks in my queues have delays (explicit or otherwise), the program quits before all tasks finish. I've currently had to put in an artifical sleep(), with an arbitrary period.

Is there a way to wait for all tasks in all queues to be complete, without explicitly having to tag every queue or queue group and then perform a

dispatch_group_wait(group, DISPATCH_TIME_FOREVER) (for the group)?

I'd still need to tag the group in the example above. I'd prefer not to have to do that.

None of the above would be necessary if it's a standard OS X or iOS App, as you'd have to explicitly quit from the App ... unless you've got a built in escape hatch, AKA bug :-)

In essence, is there a way to 'wait' for all queues to be empty, before quitting? That's similar to the wait above, without having to be explicit for each queue/group.

Thank you

Paul

Answered by DTS Engineer in 130896022

To get around the lack of a run loop, I've followed a helpful thread on StackOF - to use CFRunLoop.

Unless you actually need a run loop (because, say, you’re calling Cocoa APIs that assume a run loop) the standard practice here is to use

dispatch_main

.

As far as waiting for completion, I think that a dispatch group is the right idea. Keep in mind that you don’t need to enter the group for every block you schedule. Rather, enter the group for each unit of work then, when that unit of work is done, leave the group.

Finally, if you’re doing work asynchronously, it’s better to use

dispatch_group_notify

to learn about the completion of a group rather than

dispatch_group_wait

. The latter ends up blocking the calling thread, which is wasteful.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’16

Accepted Answer

To get around the lack of a run loop, I've followed a helpful thread on StackOF - to use CFRunLoop.

Unless you actually need a run loop (because, say, you’re calling Cocoa APIs that assume a run loop) the standard practice here is to use

dispatch_main

.

As far as waiting for completion, I think that a dispatch group is the right idea. Keep in mind that you don’t need to enter the group for every block you schedule. Rather, enter the group for each unit of work then, when that unit of work is done, leave the group.

Finally, if you’re doing work asynchronously, it’s better to use

dispatch_group_notify

to learn about the completion of a group rather than

dispatch_group_wait

. The latter ends up blocking the calling thread, which is wasteful.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 2

pnm OP

Apr ’16

Thanks Quinn,

I've got a lot to learn about queues.

Yes, I found it odd to add an artificial run loop. I'm using both the main queue as well as custom queues (async too), but I'm trying to call them from a wrapper (main piece of code) that wants nought to do with queue information whatsover. Regurgitating group and other information upstream seems to introduce coupling where perhaps it shouldn't be (trying to make code as abstract as possible). Ijust want the main code to say to the rest; "do this, do that - and tell me when you've finished".

Nohow, I'll stick my nose back in the documentation. Thank you again.

Paul

0

Answer 3

DTS Engineer OP

Apple

Apr ’16

I just want the main code to say to the rest; "do this, do that - and tell me when you've finished".

You can implement “tell me when you’ve finished” by having the wrapped code call a completion block supplied by its client. That will allow you to decouple that core from the main code that’s managing the dispatch group.

The alternative is to have the main code infer that the wrapped code is finished via some implicit mechanism, and that seems much worse from a maintenance perspective.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0