DoubleFFT_1D creating non-daemon threads causes return from main() to wait

[daw3rd]

I am doing the following (deep down in my main())

  DoubleFFT_1D doubleFFT = new DoubleFFT_1D(dataInWindow.length);
  double[] resultsFFT = Arrays.copyOf(dataInWindow, dataInWindow.length);
  doubleFFT.realForward(resultsFFT);

and when my main() returns it hangs for about 60 seconds before actually exiting the JVM. If I comment out the last line, the problem goes away. I think this is because ConcurrencyUtils uses Executors default thread factory which creates non-daemon threads.

    @Override
    public Thread newThread(Runnable r)
    {
        Thread t = DEFAULT_FACTORY.newThread(r);
        t.setUncaughtExceptionHandler(handler);
        return t;
    }

Should you be using daemon threads.

[jmpFCE2]

Is this not the same as issue #2 that has a solution?

[daw3rd]

I suppose this is the same issue. However, is the fix to have the API user call ConcurrencyUtils.shutdownAndAwaitTermination() or is that being done somewhere inside the library? If the former, I would argue that requiring the user to call that is not the best way to fix this issue since the user has to know about the problem and maybe even consult github. Why not just use daemon threads and avoid the complexity? If the latter, then I'm still getting the problem.

[jmpFCE2]

I am new to java so I cannot comment on different types of threads :) I only noticed the closed issue resembling this one and thought I would highlight it. But I agree, my code too took a long time to exit (different from the freeze issue I just submitted) and only when checking the closed issues to make sure I was not submitting an existing issue did I come across this - at least partial - solution.

[KilianB]

I came across the same issue and was about to open a new issue. For me the non daemon threads are spawned once I use a large array (e.g. 256 x 256). Calling shutdownThreadPoolAndAwaitTermination is not a viable solution as this will result in subsequent calls to fail due to the static nature of ConcurrencyUtils.

What you can do is providing your own thread pool/factory by calling ConcurrencyUtils.setThreadPool at the beginning of your application.

Still the issue remains that once your thread pool shuts down it will be replaced by the default implementation again upon submitting a new task. This can be counteracted by reflection. Overall this entire "issue" isn't really pretty to solve without changing the actual code.