I wanted to make the Uniform's into `const`s that live at the global
scope. Rust can do global const, but the `Uniform::new()` function
can't be used in that context.
As an intermediate to a *helpful* solution, I've just pushed them into a
struct. One less parameter to name even though it's the same stuff. The
compiler should be smart enough to hoist the initialization outside the
function and leave them around, but maybe not. After all, the function
isn't defined to work in such a way with the `const` keyword :v
The Stop command will be handled specially by the Dispatcher to act as a
sort of broadcast into the thread pool. Instead of asking the caller to
feed in the appropriate number of stop commands, a single one will queue
up a stop for all threads. Important for the ergonomics of having a
variable number of threads (instead of the earlier magic constant).
Moreover, it's necessary if the dispatcher stops using the round-robin
style assignment.
The pool size is specifiable as an argument to Dispatcher::new().
As results come from the dispatcher('s return channel) they are pushed
into a vector to be reordered. They're sorted in reverse-order so that
they can be popped from the vector. Upon receipt and buffering of a
scanline, a loop checks the tail of the buffer to see if it's the
next-to-write element. Since the tail is popped off, this loop can run
until this condition is not met.
Saving for reference more than anything. The threads take ownership of
the data (the closures do, but whatever). Moving the return channel out
of the dispatcher means the dispatcher can't be moved into the feeder
thread.
I see a few solutions from here:
1. Proxy the return channel with another channel. Give the whole
dispatcher to the feeder thread and hook up another output channel.
Have the feeder unload the return and pass it through.
2. Rewrite the dispatcher constructor to pass a tuple of the dispatcher
minus it's return channel, and the return channel now as a separate
object. This could let them have independent lifetimes and then I can
pass them around like I'm trying to do.
3. Have main do all the job feeding, result unloading, and
recompositing. Don't have a feeder and collector thread, and just
have main bounce between loading a few, and unloading a few.
The job dispatcher has been hooked up and four threads are rendering the
scene. There's a super important caveat, though: The job submission is
blocking and will prevent the main thread from continuing to the result
collection. The threads will be unable to contiinue without having
output space, though. Since the buffers are only size 1, this will cause
4 scanlines to be rendered, and then nothing else to be done. Deadlock.
Bumping the input buffer to 100 lets the submission loop fill up the
workload and then move on to collecting.
There's also no scanline sorting, so everything gets <<wiggly>>.
It's getting fiddly and awful keeping all the thread control pieces all
over the place. Existing ThreadPool implementations seem a little weird,
and this is a learning experience. I'll just make my own!
The dispatcher constructor only creates the threads and sets up their IO
channels. It has another method for serial submission of jobs.
The job allocation follows a round-robin selection, but I have some
concerns about starvation doing this -- consider a long running scanline
render. It would make the submission call block and other threads could
become available for that job. But they'll be ignored, since the
round-robin assignment doesn't have any skip mechanisms.
