Updating the UI is Slow about wosaic HOT 3 CLOSED

The FlickrServices2 class aggregates all of its results and then adds it to the 
shared buffer for processing.  I 
think this might be slower than letting each query add to the buffer as it 
completes, because we are 
potentially bounded by the slowest query.

Another correct solution is to add to the shared buffer as each Query 
completes.  The articles about Thread 
Pools say to be wary of doing this because it introduces the potential for 
deadlock.  Note that this is not the 
case in this shared buffer scenario, as there is no 'hold and wait' condition.  
We have each thread potentially 
waiting (not holding the lock) for one other thread to finish some simple queue 
operations (which don't 
require any additional locks).

We'll have to do some performance analysis with various combinations of these 
methods, because it isn't clear 
to me how having multiple thread pools and multiple sources (flickr, facebook, 
etc), competing for the shared 
buffer will perform.

Responding to Comment 1:

This is something that we can discuss more at the meeting. However, we are 
already
submitting progress from FlickrService2 as each query completes.  The logic is 
as
follows:

foreach query:
    Start a new thread that will specifically query flickr //non-blocking call

foreach query:
    Submit our query results to the shared buffer // blocking call

The first loop is a very quick iteration just spawning threads, but the second
actually blocks to wait for results from each call.  I believe this is the best 
way
to do it.