Use thread pool in StackGuard

[majocha]

Description

Running the task on a thread pool thread is significantly faster than spinning up a new thread.
This could improve performance with codebases that trigger the StackGuard a lot.

[github-actions]

❗ Release notes required

@majocha,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/10.0.100.md	No release notes found or release notes format is not correct

[majocha]

Turns out StackGuard starts a surprisingly high number of threads. So many that it starves some 32bit tests.

[majocha]

Benchmarking this is tricky.
Synthetic benchmarks of StackGuard do show improvement. The specific test cases here do not. The reason may be that the tests for 12322 spin up fsc and fsi in new processes so there is little to no thread reuse. I think incremental use in the IDE would show benefits, but that would require measurements to be sure.

[majocha]

It seems it is possible to reimplement StackGuard single-threaded, with much better performance. I'll close and work on that instead.

[T-Gro]

Thanks for experimenting on this @majocha .
For the 32bits tests, we might consider them less relevant - if the direction of the change helps everyone else.

[majocha]

It seems it is possible to reimplement StackGuard single-threaded, with much better performance. I'll close and work on that instead.

Yeah, I spoke too soon. I was able with some trickery to get a singlethreaded StackGuard that preserves the very useful type signature of the current one, but it breaks for anything but the most simple cases.

Interestingly, in theory it seems possible. Just replace async with some single threaded scheduler and yield instead of SwitchToNewThread(). The tricky part is yielding cooperatively without deadlocking everything.