Threading in Corona?

Solar2D General Questions/Discussion
#1

Is threading possible in Corona SDK? Does it happen automatically? If it does exist, how do I utilize it?

#2

In lua, you’ll need to use coroutines to implement multithreading.  Here’s a tutorial.

#3

Just be aware that it is not multi threading. Coroutine simply help in specific cases with the management of code execution most notably with state machine type algo.It is still just one thread executing your code.

#4

How does a modern SDK like this not support multithreading? Is is lua or the Corona SDK that doesn’t allow for multithreading? Do the other cores on devices just stay dormant while a Corona SDK lua app is running?

#5

Does the use of making a coroutine for a particularly intensive task help the app’s overall performance?

#6

For an app* I wrote that had a 10-15 second background calculation during the play of a card hand, a very carefully written coroutine keep the UI responsive and all the animations flowing smoothly. It did add a little time but not much to the overall calculation. 

In pure Lua 5.3, not Corona, I have also gotten coroutines to work well with networking/TCP code. 

* I had to port the app back to native Objective-C, where I used threads, due to other limitations in Corona I couldn’t overcome. 

#7

If the “particularly intensive task” is a one-time or occasional thing then it’s a good candidate, assuming said process can be broken down into steps (versus say loading a larger texture), and I tried to convey that in the tutorial. When something must be done all at once and on every frame, on the other hand, you’re better off improving your algorithms and / or data structures. Of course, sometimes coroutines themselves enable useful techniques.

mbrennan posted while I was writing; basically, there’s a case study for my first sentence.  :slight_smile:

For what it’s worth, I’ve also bound a threading library, currently just for personal use. (My fork has some fixes for Visual Studio.) I still need to make some changes to the shutdown behavior. Right now, if you have unmatched receive ()s or send ()s pending (easy enough to do during development), it will lock up when you try to relaunch. Once I address that, I’m considering submitting it as a plugin, though at the moment I don’t have any Apple products to build or test on, so I’d only be hitting half the possibilities.

I’ve been using it to communicate with other Win32 processes, where there’s a lot of sitting around waiting for input to arrive (or not!). I imagine it would also be useful for heavy, isolated Corona-agnostic tasks: number-crunching, decompression, parsing large files. This sort of programming tends to be something of a chore, though; if a coroutine would suffice, it’s generally the better way to go.

#8

The GitHub link you submitted seems promising. It would be really cool to see that as an official plugin!

#9

Question:  “What would you use it for if it did?”  You’d have to code for it and that is no simple task.  If you introduce this kind of feature and try to use it you have to care about:

Note: Just because an environment supports multi-threading (say Linux), doesn’t mean every app is multi-threaded automatically.  One has a do a lot of (advanced) coding to take advantage of multi-threading.

Also, while I’m sure there are cases where people would find all the heavy lifting worth it, typically a 2D game or a mobile app won’t benefit from it anyways.  You typically see this used (sparingly) in 3D games with heavy discrete tasks (AI is one of the major users of threading,but there are others).

Some (possibly interesting) reading:

#10

I would say no.  

The primary benefit of co-routines is the ability to suspend the animation of a piece of code till later. 

  • Keeps it from blocking progress of the entire app (as long as the app is not dependent on the output of the function)
  • Allows you to spread non-critical  heavy-lifting / long-running code over many frames/cycles (again to avoid blocking and FPS dips).

Note: If your code is step-wise dependent on the output of a function, using co-routines will not help at all AND will actually be slower since now you’re paying for the: wrapping, suspending, waking, checking (on state), etc…

Whatever you do, you’re still running in a single thread.  

#11

In lua, you’ll need to use coroutines to implement multithreading.  Here’s a tutorial.

#12

Just be aware that it is not multi threading. Coroutine simply help in specific cases with the management of code execution most notably with state machine type algo.It is still just one thread executing your code.

#13

How does a modern SDK like this not support multithreading? Is is lua or the Corona SDK that doesn’t allow for multithreading? Do the other cores on devices just stay dormant while a Corona SDK lua app is running?

#14

Does the use of making a coroutine for a particularly intensive task help the app’s overall performance?

#15

For an app* I wrote that had a 10-15 second background calculation during the play of a card hand, a very carefully written coroutine keep the UI responsive and all the animations flowing smoothly. It did add a little time but not much to the overall calculation. 

In pure Lua 5.3, not Corona, I have also gotten coroutines to work well with networking/TCP code. 

* I had to port the app back to native Objective-C, where I used threads, due to other limitations in Corona I couldn’t overcome. 

#16

If the “particularly intensive task” is a one-time or occasional thing then it’s a good candidate, assuming said process can be broken down into steps (versus say loading a larger texture), and I tried to convey that in the tutorial. When something must be done all at once and on every frame, on the other hand, you’re better off improving your algorithms and / or data structures. Of course, sometimes coroutines themselves enable useful techniques.

mbrennan posted while I was writing; basically, there’s a case study for my first sentence.  :slight_smile:

For what it’s worth, I’ve also bound a threading library, currently just for personal use. (My fork has some fixes for Visual Studio.) I still need to make some changes to the shutdown behavior. Right now, if you have unmatched receive ()s or send ()s pending (easy enough to do during development), it will lock up when you try to relaunch. Once I address that, I’m considering submitting it as a plugin, though at the moment I don’t have any Apple products to build or test on, so I’d only be hitting half the possibilities.

I’ve been using it to communicate with other Win32 processes, where there’s a lot of sitting around waiting for input to arrive (or not!). I imagine it would also be useful for heavy, isolated Corona-agnostic tasks: number-crunching, decompression, parsing large files. This sort of programming tends to be something of a chore, though; if a coroutine would suffice, it’s generally the better way to go.

#17

The GitHub link you submitted seems promising. It would be really cool to see that as an official plugin!

#18

Question:  “What would you use it for if it did?”  You’d have to code for it and that is no simple task.  If you introduce this kind of feature and try to use it you have to care about:

Note: Just because an environment supports multi-threading (say Linux), doesn’t mean every app is multi-threaded automatically.  One has a do a lot of (advanced) coding to take advantage of multi-threading.

Also, while I’m sure there are cases where people would find all the heavy lifting worth it, typically a 2D game or a mobile app won’t benefit from it anyways.  You typically see this used (sparingly) in 3D games with heavy discrete tasks (AI is one of the major users of threading,but there are others).

Some (possibly interesting) reading:

#19

I would say no.  

The primary benefit of co-routines is the ability to suspend the animation of a piece of code till later. 

  • Keeps it from blocking progress of the entire app (as long as the app is not dependent on the output of the function)
  • Allows you to spread non-critical  heavy-lifting / long-running code over many frames/cycles (again to avoid blocking and FPS dips).

Note: If your code is step-wise dependent on the output of a function, using co-routines will not help at all AND will actually be slower since now you’re paying for the: wrapping, suspending, waking, checking (on state), etc…

Whatever you do, you’re still running in a single thread.