I have a somewhat unusual use-case that I’m trying to figure out.
I have a command-line swift app whose main thread ends up in an infinite loop for graphics rendering purposes (running SDL).
What I’m hoping to do is to be able to run async code like this from within that infinite loop:
DispatchQueue.someQueue.async {
// do something
DispatchQueue.main.async {
// return result
}
}
The issue is that the DispatchQueue.main.async block never runs, which is pretty logical given that it’s called inside the infinite loop - so where would it possibly get to run?
The question is, how do we achieve this? Is there a better way to have an infinite loop on the main thread (e.g. Foundation’s RunLoop class etc)? On iOS (where I have the most experience with Swift), the rendering loop’s implementation is obviously hidden.
Theoretically we could probably do the entire rendering loop like this:
func renderStuff() {
// actually render stuff
if !shouldQuit {
DispatchQueue.main.async(renderStuff) // loops here
}
}
The issue is that the *DispatchQueue.main.async* block never runs, which
is pretty logical given that it’s called *inside *the infinite loop - so
where would it possibly get to run?
The question is, how do we achieve this? Is there a better way to have an
infinite loop on the main thread (e.g. Foundation’s RunLoop class etc)? On
iOS (where I have the most experience with Swift), the rendering loop’s
implementation is obviously hidden.
Theoretically we could probably do the entire rendering loop like this:
Something has to drain blocks sent to the main queue.
You can run a Foundation run loop. That should drain the main queue. I believe it also ensures blocks sent to the main queue always run on the main thread.
Dispatch includes its own lower-level function to pump the main queue: dispatch_main. This does not return. It does not ensure main queue blocks run on the main thread. The main queue does remain the only default, global, serial queue.
Both the Foundation and Dispatch APIs support creating custom event sources. A custom event source lets your integrate processing your own events with the framework’s main run loop. You might investigate those event source APIs as a way to integrate your SDL rendering code with whichever run loop you select. (If you expect to use Foundation, you probably want to run its RunLoop.)
Don’t forget to drain the autorelease pool associated with your main run loop regularly.
On Oct 4, 2017, at 21:07, Rahul Ranjan via swift-users <swift-users@swift.org> wrote:
Hi Geordie,
I am new here and so pardon me if I misunderstood anything.
When you run a program in Swift, it already runs on main thread by default and then you can all Dispatch async. So for example,
while true { // This while loop will run for infinite on main thread
Dispatch.main.async {} // your rendering goes here.
}
Regards,
Rahul
On Thu, 5 Oct 2017 at 2:45 AM, Geordie J via swift-users <swift-users@swift.org> wrote:
Hi!
I have a somewhat unusual use-case that I’m trying to figure out.
I have a command-line swift app whose main thread ends up in an infinite loop for graphics rendering purposes (running SDL).
What I’m hoping to do is to be able to run async code like this from within that infinite loop:
DispatchQueue.someQueue.async {
// do something
DispatchQueue.main.async {
// return result
}
}
The issue is that the DispatchQueue.main.async block never runs, which is pretty logical given that it’s called inside the infinite loop - so where would it possibly get to run?
The question is, how do we achieve this? Is there a better way to have an infinite loop on the main thread (e.g. Foundation’s RunLoop class etc)? On iOS (where I have the most experience with Swift), the rendering loop’s implementation is obviously hidden.
Theoretically we could probably do the entire rendering loop like this:
func renderStuff() {
// actually render stuff
if !shouldQuit {
DispatchQueue.main.async(renderStuff) // loops here
}
}