Can we have multi threading ?

Clearly the response is NO. Because corona work on single thread.
I tried Love2d, has a function where you can pass a code that is executed in an other thread. This work well also on Android. Can we have something similar in Corona?

I try to see if this is possible writing a custom plugin that work for Android and iOS.
But i’m not an expert of Lua execution i don’t know how run a lua code in an other thread get the result and return into the main thread in async.

My goal is have a long process execution non blocking the UI. Coroutine is not an option.

Any help will be appreciated.

1 Like

Well, I think the answer is yes, but unless I’m mistaken, it would need to be added to Solar2D core and I have no idea how difficult or how much work adding support for something like that might entail.

Not an expert on the subject but it may be a good idea to look at how Löve pulls it off. If they are using an extension library then it might be the way to go but if it’s a core stuff as @XeduR says then someone needs to get their hands dirty. Then this might be a good idea to make a feature request (I doubt that it will be high priority) or you should look into it.

By the way, when you search for multithreading in Lua returns some result like LuaLanes and more. Have you looked into those?

@bgmadclown I have looked a lot of stuffs, i start to search years ago but not found nothing that i’m able to integrate in corona and build in Android and iOS.

Maybe how suggests @XeduR, the correct way is have the feature implemented into Solar2D core.

I don’t know the Solar2D core, i think that i’m not able to implement a feature like this into the core.

How do you suggest to proceed?

For me is a really important feature, now i’m forced to show a static loading and block the UI for a lot of seconds. I can also think to start to study for implement this feature but i don’t know where to start, i don’t know anything about the core and how Solar2d is builded.

Hi.

I have a rather heavy modification of luaproc available as a plugin. You can find it on the official marketplace, but that’s being sunsetted, of course. As I mentioned when posting my plugins’ source yesterday, I’ll probably camp builds there once I become acquainted with the (new to me) process.

The plugin source is here, docs here, and some samples here.

There should be something like “STEVE CHANGE” wherever I’ve modified the original files.

It grew into a Frankenstein’s monster of sorts, incorporating non-luaproc libraries, since it was a paid plugin and that discouraged making auxiliary plugins to go with it. I might now try to break it up a bit.

The other threads can run Lua code, but not Solar2D APIs except where I went to the effort of emulating them (to some extent). I honestly don’t think trying to do much more is worth it, but who knows.

I also made the serialize plugin in part to allow marshaling data between threads. (In the “Research” section of my source repository landing page, you can even see some student projects looking to extend luaproc proper in this way.)

Furthermore, I have Submit and Sync methods in my memory blob objects that essentially just swap the underlying references, for near-instant bulk exchange across threads. I have samples here, though I don’t remember if this is the most recent version: serialize_luaproc_memoryblob_sample.zip (292.8 KB) This was experimental for a long time, but I finally hammered out the kinks in it some time last year. I was actually planning to add something along these lines back into serialize, though I forget off-hand where that’s at (in other words, I don’t know if those samples are appropriately titled :smile:).

Threading is hard. There’s a LOT of tacit knowledge in developing these plugins and getting them and others to play well together, that’s all just sort of sitting there in my mind. I would love to get more eyes and hands on this stuff, though!

4 Likes

@StarCrunch thank for the work and the links

What is the correct way to use a plugin in this list https://github.com/ggcrunchy/solar2d-plugins?

@donati.sergio Hi. I’ll try to have non-marketplace instructions up soon, but I’m still in the middle of getting that figured out. :slight_smile: I expect you’ll want to look over this, at least.

On Windows I use Git Bash and Terminal on Mac. In either case you can do git clone --recursive https://github.com/ggcrunchy/solar2d-plugins.git (you could also just grab the zip from GitHub, but make sure you also grab the two submodules too).

I’ve been using Visual Studio 2013 on Windows (Community Edition is fine), and that did work when I tested just now. But I’ll try 2019 in the near future; I would try going right to that. (2013 can be a bit of a chore to find, anyhow.) It might be enough to just convert the solutions (just open them up in 2019).

Otherwise, start with the “Development Tools” mentioned here.

Android will also need the NDK. Again, I’ve been using an iteration of version 20, but plan to move on to 21. These lines in the various Android plugins will need some adjustment, both for the NDK version and your own setup.

My Android build also seemed okay. I haven’t tried the Apple stuff yet, to make sure renaming one of those submodules didn’t break anything. Will get back on this.

If you go into the Windows solution and build in Release, a post-build event will put the DLL in "%appdata%/Corona Labs/Corona Simulator/Plugins/plugin/". (I think I have the Mac build doing something similar.)

On the other platforms, you want to cd to the plugin/platform directory, e.g. path/to/luaproc/ios in Terminal, then type ./build.sh. If all goes well, you’ll see new binaries appear under jniLibs on Android, in the main directory on Mac and iOS, or in the non-simulator release folder for the TV.

The first time you try to run this file (and some other things, copy-pasting maybe, can introduce this), you’ll get some permission complaints unless you first do chmod u+x build.sh.

That’s what comes to mind at the moment.

This would be great! I would be vote for this feature.