Use tokio only if running from a multi-thread tokio context

[viirya]

Which issue does this PR close?

Closes #7206.

Rationale for this change

What changes are included in this PR?

spawn_buffered function will use tokio context to spawn the execution of stream if tokio runtime is started. However, if the started runtime is current-thread and it is blocked on, spawned tasks could be possibly dead-locked.

Are these changes tested?

Manually tested in internal code if using current-thread tokio runtime.

Are there any user-facing changes?

[alamb]

This improvement makes sense to me. Thank you @viirya

I looked into where this code was used and it is part of sort / merge in case anyone else is interested:

https://github.com/search?q=repo%3Aapache%2Farrow-datafusion%20spawn_buffered&type=code

I don't understand why this change would prevent a deadlock, though 🤔 I would have thought it was related to using blocking I/O in the sort

https://github.com/apache/arrow-datafusion/blob/2d91917bb66542a44c31b7a306512bb4e09b5298/datafusion/core/src/physical_plan/sorts/sort.rs#L550-L579

Maybe we should use async IO in the sort 🤔

[viirya]

I don't understand why this change would prevent a deadlock, though 🤔 I would have thought it was related to using blocking I/O in the sort

I have used a current-thread tokio runtime to execution a query plan which contains Sort operator so it spawns sort tasks in the end. As the current thread is blocked on the query itself, spawned tasks are waiting for thread but never get it possibly because the query waits for spawned tasks too.

I think the issue I encountered is less related to IO here but more related to the tokio runtime.

So this change is to prevent such case.

[viirya]

Merged. Thanks @alamb