Getting started with threads in D

[Henrik Valter Vogelius Hansson]

> Games are an odd bird in that performance comes at the expense 
> of much else, and that it really isn't easy to parallelize the 
> main loop.  That said, the only time the concurrency library 
> would halt a thread is if you do a receive() with no timeout 
> and the message you want isn't in the queue.  So you can bypass 
> this by using a timeout of 0 (basically a peek operation), and 
> changing the code path based on whether the desired message was 
> received.

Well it also depends on how you do the receive. Though right now 
I am thinking of like a lazy evaluation, so I only try to receive 
the messages(with timeout) where I expect to use them instead of 
doing it all on the same place. And the same goes on the other 
end. Well might be over thinking it cause it's starting to sound 
more and more like how I used to work before I tried task pools. 
And I guess it won't be added in the near future so you can 
specify thread id's to the task? Like all OpenGL-related tasks 
get a specific thread while all other's doesn't matter.

> Can ownership of an OpenGL/DirectX contact be passed between 
> threads?  Can you maybe just give every thread its own context 
> and let it process whatever task you give to it, or is a 
> context necessarily linked with some set of operations?

Ownership can not be passed between threads. And giving every 
thread it's own context is possible but is bothersome because for 
instance the different context would have different states. 
(Backface culling, depth settings, and so on) Plus it would be 
pretty slow because I would have to call glFlush or similar to 
force the drivers to make sure all texture data has been updated 
to all threads and so on. Most of these problems with context and 
threads I have learned through the hard way :P

If you have a opinion in what you think would be the best way to 
do this then I am interested, even if it is single threading it. 
But I want a motivation of course. Otherwise I'll just go with 
the concurrency library and lazy evaluation idea. I'll probably 
profile a little and do a consideration over what is easiest to 
work with and expand on later as well.