Hey there!

I'm trying to figure out which of D's many multithreading options to use for my application. I'm making a game that runs at 60 frames per second that can also run user-made Lua scripts. I would like to have the Lua scripts run in a separate thread so they can't delay frames if there's a lot of work to do in a burst, but I also need it to be able to update and read from the thread where everything else is.

I don't think message passing is going to cut it because the Lua thread is going to need to be able to request to set a value in D on one line, and then request that value back on the next line, and that value needs to be updated at that point, not at the end. I've been marking things as __gshared to get them working, but I think that just makes a copy on all threads, which seems pretty excessive when mostly the Lua will just be reading values, and occasionally calling a function in D to change some values.

I think I should try to do some kind of lock thing, but I'm not really sure how that works. If someone could advise me on what tact I should take, that would be very helpful.

Thanks!

On 3/4/18 11:31, Drew Phil wrote:
> Hey there!
>
> I'm trying to figure out which of D's many multithreading options to use
> for my application. I'm making a game that runs at 60 frames per second
> that can also run user-made Lua scripts. I would like to have the Lua
> scripts run in a separate thread so they can't delay frames if there's a
> lot of work to do in a burst, but I also need it to be able to update
> and read from the thread where everything else is.
>
> I don't think message passing is going to cut it because the Lua thread
> is going to need to be able to request to set a value in D on one line,
> and then request that value back on the next line, and that value needs
> to be updated at that point, not at the end. I've been marking things as
> __gshared to get them working, but I think that just makes a copy on all
> threads, which seems pretty excessive when mostly the Lua will just be
> reading values, and occasionally calling a function in D to change some
> values.
>
> I think I should try to do some kind of lock thing, but I'm not really
> sure how that works. If someone could advise me on what tact I should
> take, that would be very helpful.
>
> Thanks!

core.thread is probably your best bet in the long-term. std.concurrency could actually be used though, just call receive() immediately after send(). However, the performance of this may not be what you want. My recommendation would be to use std.concurrency to get the logic correct first, then worry about perf. And using std.concurrency will get some of the basic concepts (ex: immutable/shared) right that will port over the regular threads.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;