Introspect runtime flavor/configuration on Handle

[mooso]

Some functions in tokio, such as block_in_place(), only work in a multi-threaded runtime. It would be great to be able to inspect the current configuration/flavor of the runtime so that we can conditionally call such functions, e.g.:

if Handle::current().is_multi_threaded() {
    block_in_place(move || { long_running_code(...) })
} else {
    long_running_code(...)
}

[carllerche]

I'm fine w/ this. Handle is a pretty safe place to put these fns.

[Darksonn]

I don't mind adding such a method, but I am worried about the example you are showing us. The only situation where block_in_place would panic is in a current-thread runtime or LocalSet, i.e. in places where it is not okay to block. In particular, it does not panic if used outside of a runtime. Because of this, it seems to me that any situation where your code has different behavior from just always using block_in_place is a situation where your code is incorrect.

[mooso]

I am probably missing something @Darksonn - why would it not be OK to run some long running code in a current-thread runtime? Sure any other scheduled tasks will be blocked from running until the long running code is done, but that's just a perf degradation not a correctness issue right? In my use case the real perf-sensitive scenarios will always run with multi-threaded runtime, but some integration tests will run on current-thread runtimes and I just need them to be correct, not necessarily fast.

[Noah-Kennedy]

This is more about what is good vs bad practice than what is a bug or not, but in general any code that "blocks" the runtime is bad, and honestly moreso if it's in the current_thread runtime, which is very useful for perf-sensitive scenarios.

[Darksonn]

While what you're saying is true, the perf degradation is generally so bad that its unacceptable in pretty much every situation, but I admit that tests are probably a counterexample to that.

[Noah-Kennedy]

Fair point.