Another possibility for the communication between the data and render threads.

Another possibility for the communication between the data and render threads.

QLocal{Server,Socket} -- on UNIX systems, a "domain pipe" (according to the Qt
documentation, which is, of course, a UNIX pipe). I could potentially use a
pipe between the rendering thread and the storage thread . . . but I'm not
sure if the added overhead would be worth it. However, it is definitely a
viable option.

I have three options, now. I can do the obvious but probably very slow way,
which is using Qt signals and slots. While convenient, they are definitely not
optimal, as far as speed is concerned. I can also create two producer/
consumer-style queues that each thread maintains. However, what happens when I
have multiple rendering threads (not an unlikely possibility)? Additional
queues need to be created, which isn't exactly going to help speed or memory
usage . . .

And, of course, there's the sockets. Out of the three, I think I like the
queues most. It's fairly flexible, doesn't use an insanely large amount of
memory, and is fast enough for my purposes . . . I think.

I'll give it a try, though I doubt I'll actually end up with any better
solutions, at least not without redesigning anything else.