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;
