Daemonize OkHttp dispatcher threads.

[GrahamDennis]

No description provided.

[uschi2000]

What's the rationale here, @GrahamDennis ?

[GrahamDennis]

What's happening is that the CachedThreadPool can cache the threads for 60s after they've last been used. So the threads can delay termination of a process by up to 60s if the process doesn't call System.exit.

My rationale for this change is that even if an OkHttp client is using one of these threads, a non-daemonized thread should be blocking on the response. But I suppose if you're instead only being notified when the response comes back, then these threads could be feasibly be the only non-daemonized threads running, in which case this would be the wrong change to make.

[uschi2000]

My understanding of daemon threads (which may be inaccurate) is: the JVM will terminate automatically once all active threads are daemon threads. I don’t think ever rely on this mechanism though, because we always explicitly terminate the JVM through signals, no?

[GrahamDennis]

You're right that it doesn't matter either way for servers... However I've been using this in some CLIs. It's for the benefit of a CLI that I initially wanted to make this change.

However, I've since realised that what I should be doing is calling System.exit when my CLI is done instead of relying on the JVM to clean up when all non-daemon threads are complete. So I think we can close this out as I don't need it anymore. And I'm actually not sure that my proposed change is correct, because if you were running a CLI and were asynchronously listening for a HTTP response, the OkHttp thread could be the only non-daemonised thread, and I think we would not want the JVM to terminate in that situation.

[dansanduleac]

FWIW, the Dispatcher's default ExecutorService implementation also creates non-daemon threads, so I just copied that when creating this executionExecutor.

[carterkozak]

lots of conflicts, we should remake this