• Drew Phil (20/20) Mar 04 2018 Hey there!
• Adam Wilson (12/31) Mar 04 2018 core.thread is probably your best bet in the long-term. std.concurrency

Drew Phil <sdfdddsssf gmail.com> writes:

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!

Adam Wilson <flyboynw gmail.com> writes:

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;