Looks good, thanks! Are there any reasons we shouldn't just make this the default?

BTW, NO_JNI_DETACH_THREAD isn't needed on Linux and Mac anymore. They do not get detached before they exit anyway.

Are there any reasons we shouldn't just make this the default?

I suppose it is possible for the an application to terminate mid-callback when the thread is a daemon. This is not possible with the default behavior, since the thread will only disappear once the callback is complete. I don't know if this an actual problem though.

I'm fine either way, let me know what you prefer and it will be done.

BTW, NO_JNI_DETACH_THREAD isn't needed on Linux and Mac anymore. They do not get detached before they exit anyway.

So threads are reused by default on these platforms? Won't that prevent the application from closing normally (forcing use of System.exit()).

So threads are reused by default on these platforms? Won't that prevent the application from closing normally (forcing use of System.exit()).

Maybe that's why we shouldn't try to consider those threads to be managed by Java and initialize them as daemon...

Let me make some tests to see if there are any issues.

I think the whole concept of "daemon threads" in Java is to replace the implicit call to exit() when returning from the main() function in C. Java doesn't do that, so they had to come up with some other convention, and that's what they ended up settling on I guess. In a native application, all threads are therefore in that sense "daemon" since whenever we return from the main() function, the program exits. Consequently, I think it makes sense to consider all those threads created on the native side to be "daemon", since native libraries expect them to work that way anyway.

I'm pretty happy with the changes, assuming they build. Threads are now always attached as daemons. See the associated test case; I've independently verified using my Decklink Bindings.

Side note; it might be worth tracking thread attachment using thread_local storage. My understanding is that thread_local is automatically destroyed upon thread termination; meaning we can detach in the destructor. If this works, then we can make NO_JNI_DETACH_THREAD the default behavior for windows as well.

Thoughts? Should be pretty easy to implement and test; I don't mind doing it here or in another branch.

Side note; it might be worth tracking thread attachment using thread_local storage. My understanding is that thread_local is automatically destroyed upon thread termination; meaning we can detach in the destructor. If this works, then we can make NO_JNI_DETACH_THREAD the default behavior for windows as well.

Thoughts? Should be pretty easy to implement and test; I don't mind doing it here or in another branch.

Sounds like a good idea! If it works, we can try to make this the default on all platforms when C++11 is detected.

BTW, even if you implement detach using thread_local, you may very well end up using NO_JNI_DETACH_THREAD in your application anyway to avoid overhead from that. So let's merge this and you can work on it when you have time?

I can do it separately.