A temporary work-around

So, you know what would make the difficulties associated with returning asynchronously a non-issue? Starting out by solving a problem such that we only need to compute and store results and not return values of our asynchronous computation!

So, instead of computing our Mandelbrot set as a grid, we're going to take a recursive, vaguely functional approach - basically accepting a range over which to compute the Mandelbrot Set in the form of a top left corner and a bottom right corner. If these points are sufficiently near to one another, we will generalize a single point from them and compute whether that point is in the Mandelbrot set, storing the result in a two-dimensional array at the end of the computation.

If the points are *not* sufficiently near to one another, we will divide the range into quadrants and compute the Mandelbrot Set values of each of those ranges.

It is this compute_on_range method that I will apply my asynchronous method generation to.

It's a far cry from a perfect solution. It's a more functional route than I wanted to take. If people want to do functional programming and have concurrency/parallelism taken care of for them, there are already lots of options. The very nature of functional programming simply lends itself better to concurrency - at least in my opinion. I was hoping to minimize the need to redesign code for concurrent performance, and this is not remotely a typical imperative/OO way of computing the Mandelbrot set.

Since we're relying on instance variables to avoid assignment, it means I also don't get to test my theories about using bindings and lambdas to avoid mutex problems. It is, however, a start. Hopefully I'll have this simplified variant finished by the end of this weekend - assuming I can muster up the motivation...