Use of cached thread pool in gaze listener calls.

[karthik]

In the GazeManager.activate method, you create a cached thread pool (line 159) instead of a fixed thread pool. As a result, if I put a breakpoint in my GazeListener method, I'm pretty much toast! There are an endless number of threads that get spawned since at any given point the threads that subsequently come in hang. You should perhaps consider accepting an optional configuration object in the activate method wherein the user can specify the number of threads that should be used or you should use a fixed size thread pool.

[Anders]

Hi

The underlying idea is to balance out the load on the underlying SDK in situations where there are many registered listeners IGazeListeners.

Unintentional locking the callback thread when debuggin causes the side effect you here describe. We will consider optional constructors in GazeManager that either allows you to set the size of the threadspools or allow you to define that you are running in debug mode.

For now I hope you have gone ahead and made the changes to the SDK in your setup yourself.

BR,
Anders