Improve thread troubleshooting experience

[gluck]

Rx can create threads in various conditions (NewThreadScheduler, EvenLoopScheduler, ThreadPoolScheduler.ScheduleLongRunning, ConcurrencyAbstractionLayer ...), resulting in any leak being impossible to track down to the cause.

Today with the PlatformEnlightmentProvider one can inject thread factories in some of these places, allowing the user to inject troubleshooting information when threads are created such as:

• debug log before creating thread
• propagate thread local data
• forcing background threads
• formatting extra info into the thread name, such as:
  • parent thread name
  • current UI view/form/window/scene

(in case the user is repacking Rx, he can include the assembly name as well, very useful to us ! - but I digress)

If you ever troubleshoot an application with a thread leak and 200+ Rx threads all called "Thread-#XX", maybe you know where this request comes from :)

[akarnokd]

I'm not sure this can be reasonably solved. Schedulers and their backing threads are orthogonal to the flows they service and without injecting context information deeply, there isn't much to be done in general. I usually suggest adding a doOnEach (Do) operator which sets the current thread's name to something contextual to the user that helps identify what was happening when a thread dump is taken later.

[bartdesmet]

Agreed with @akarnokd on the hard part being correlating scheduler (and thus sometimes thread-related) activity and the higher-level operations being served (i.e. query evaluation). This said, we can likely add minimal support to make diagnostics a little bit easier by virtue of allowing users to have more control over the name of threads created by the library (e.g. parameters on constructors for EventLoopScheduler etc.). I'll have a look into that aspect.