GH-35176: [C++] Add support for disabling threading for emscripten

[joemarshall]

As previously discussed in #35176 this is a patch that adds an option ARROW_ENABLE_THREADING. When it is turned off, arrow threadpool and serial executors don't spawn threads, and instead run tasks in the main thread when futures are waited for.

It doesn't mess with threading in projects included as dependencies, e.g. multithreaded malloc implementations because if you're building for a non threaded environment, you can't use those anyway.

Basically where this is at is that it runs the test suite okay, and I think should work well enough to be a backend for pandas on emscripten/pyodide.

What this means is:

1. It is possible to use arrow in non-threaded emscripten/webassembly environments (with some build patches specific to emscripten which I'll put in once this is in)
2. Most of arrow just works, albeit slower in parts.

Things that don't work and probably won't:

1. Server stuff that relies on threads. Not a massive problem I think because environments with threading restrictions are currently typically also restricted from making servers anyway (i.e. they are web browsers)
2. Anything that relies on actually doing two things at once (for obvious reasons)

Things that don't work yet and could be fixed in future:

1. use of asynchronous file/network APIs in emscripten which would mean I/O could work efficiently in one thread.
2. asofjoin - right now the implementation relies on std::thread - it needs refactoring to work with threadpool like everything else in arrow, but I'm not sure I am expert enough in the codebase to do it well.

• Closes: [C++] Add support for disablging threading for emscripten #35176

[joemarshall]

@kou - I've done those tidying up fixes (use of auto, extraneous return statements etc.)

Those two test cases that you flagged, I checked through them again, and I think I was wrong - they probably don't really make sense in single-threaded mode as they're testing essentially multithreaded behaviour. I've just skipped those tests in single threaded mode.

The description at the top of the PR is up to date now (and has a brief changelog of what changed from initial PR), so hopefully good to go.

thanks
Joe

[kou]

The description at the top of the PR is up to date now (and has a brief changelog of what changed from initial PR)

Could you replace the initial description directly instead of adding a new "Updated since initial PR:" section?
The latest decision is the most important thing for us.
If we want to see the history, we can use GitHub's history view UI. (See the "edited" pull down in the top of the description area.)

[joemarshall]

The description at the top of the PR is up to date now (and has a brief changelog of what changed from initial PR)

Could you replace the initial description directly instead of adding a new "Updated since initial PR:" section? The latest decision is the most important thing for us. If we want to see the history, we can use GitHub's history view UI. (See the "edited" pull down in the top of the description area.)

Okay, it's up to date.

[joemarshall]

@kou think we're good to merge now?

[kou]

@github-actions crossbow submit test-ubuntu-22.04-cpp-no-threading

[github-actions]

Revision: a4bfd80

Submitted crossbow builds: ursacomputing/crossbow @ actions-0e4eae872c

Task	Status
test-ubuntu-22.04-cpp-no-threading

[kou]

+1

The failure is #37067 .

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit b668595.

There were 2 benchmark results indicating a performance regression:

• Commit Run on ursa-i9-9960x at 2023-08-12 07:55:52Z
  • file-read (R) with compression=uncompressed, dataset=fanniemae_2016Q4, file_type=feather, language=R, output_type=dataframe
  • file-read (R) with compression=lz4, dataset=fanniemae_2016Q4, file_type=feather, language=R, output_type=table

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.