Implement Executor/thread pool

[GoogleCodeExporter]

As discussed in Issue 196 and Issue 200 this patch implements a single static 
Executor to serve all threads for all tile provider modules.

Original issue reported on code.google.com by kurtzm...@gmail.com on 15 May 2011 at 10:50

Attachments:

• Executor.patch

[GoogleCodeExporter]

This involves changing the threading architecture which is a vital section of 
code and one where problems can be hard to spot and can cause performance drain 
if malfunctioning.

I would like to see some information showing that this approach has advantages 
over what we have been using. I also question if having one big thread pool 
from which all modules feed off of is a good idea. If the tile downloader 
starts eating up threads and the pool gets starved, then the whole map stops 
drawing tiles even if they are already cached. If there really is a significant 
advantage to using an Executor, then we may also have to add some more 
sophistication to get it working optimally.

Original comment by kurtzm...@gmail.com on 15 May 2011 at 10:55

[GoogleCodeExporter]

Issue 196 has been merged into this issue.

Original comment by kurtzm...@gmail.com on 15 May 2011 at 11:05

[GoogleCodeExporter]

So, the main advantage is that the ExecutorService will keep reusing the 
threads rather than constantly creating new ones. We create a *lot* of threads, 
so this is probably worth it. Each provider module should have its own 
ExecutorService and each provider should dictate how many threads should be 
dedicated to the module.

Original comment by kurtzm...@gmail.com on 3 Jun 2011 at 7:37

[GoogleCodeExporter]

This is a much more simple version that follows our current pattern of each 
module provider having its own thread pool (or now an ExecutorService).

Original comment by kurtzm...@gmail.com on 3 Jun 2011 at 7:52

Attachments:

• Executor.patch

[GoogleCodeExporter]

Original comment by kurtzm...@gmail.com on 3 Jun 2011 at 7:52

• Changed state: Started

[GoogleCodeExporter]

And one more change - this patch allows the adjustment of the thread priority 
and it originally set it to MIN_PRIORITY. I am not sure of the effects of this 
beyond the obvious and that is not how we previously set the priority so I am 
going to leave the ability to adjust it later, but set it to normal priority 
for now.

Original comment by kurtzm...@gmail.com on 3 Jun 2011 at 8:14

[GoogleCodeExporter]

Fixed by r938.

Original comment by kurtzm...@gmail.com on 3 Jun 2011 at 8:17

• Changed state: Fixed