can revert this, but trying to get arg order consistent across most involved functions

old behavior resulting in OperationCanceledException

does it change RunSynchronously implementation?

@majocha in the PR as it stands, the core impl of RunSynchronouslyImmediate is:
https://github.com/bartelink/fsharp/blob/013acc1fca33bdfcd6f978d531bc0c6e1e34c199/src/FSharp.Core/async.fs#L1157

1. that new code is based on OP of Add Async.RunImmediate fsharp/fslang-suggestions#1042 (comment)
2. RunSynchronously used to delegate to https://github.com/dotnet/fsharp/pull/19804/changes#diff-7045116fe4610c3375ffcdd7df2ee411e71879bdf25890c8d3cf047c1b5208e2L1141 where conditions allow (no thread hop required)
3. RunSynchronously now delegates to 1

The key diff is that:

• the old way with the ResultCell Commit would result in OperationCanceledException being observed by caller if cancellation happened during running
• the new way is tcs.Task.GetAwaiter().GetResult(), which results in a TaskCanceledException (which, to the best of my knowledge does not provide a way to wire in the CT info)

The pros from my perspective are:

• RSI is simple and direct and matches the OP, without coupling to ResultCell
• if/when we ever get to split RunSynchronously into orthogonal easy to explain concepts and/or methods then those impls will tie to more ubiquitous things like TaskCompletionSource
• nobody needs to debug or reason about actual RSI vs the RSI-but-with-ResultCell-via-RS differences

Not an easy call, which is why I'm looking for someone else to vouch for it!

moved up as required by RunSynchronously

note the whole PR could be made much shorter by having the Async layer call Async.FromContinuations

However, as mentioned in other places, I believe its for the best that RunSynchronouslyImmediate and the immediate path of RunSychronously should have strong clear ties in the lower layer as this PR does

SynchronizationContext.SetSynchronizationContext ctx
async { return 1 } |> Async.RunSynchronously   // ctx.Post called 0 times; runs inline

• "on a threadpool thread" -- false (fast-path is inline)
• "honoring the ambient SynchronizationContext" -- false (never posts)

- /// <summary><p>Runs the asynchronous computation on a threadpool thread, honoring the ambient
- /// <see cref="T:System.Threading.SynchronizationContext"/>.</p>
+ /// <summary><p>Runs the computation and blocks the caller until it completes. Runs inline on the
+ /// calling thread when it is a thread-pool thread with no ambient SynchronizationContext and no
+ /// timeout; otherwise runs on the thread pool.</p>

Your wording feels much better (I was aware that my wording was technically not 100% correct - my aim was to emphasize the core difference vs RSI: even if you are doing something tiny, you'll incur a thread hop more often than you might expect from the name).

Also wanted to be pedantic on some specifics:

on a threadpool thread" -- false (fast-path is inline)

but fast path requires you to already be on a thread pool thread. So RunSynchronously didnt need to do a hop, but the code is run on a thread pool thread?

"honoring the ambient SynchronizationContext" -- false (never posts)

I think this is due to special casing triggered by the reuseThread = true parameter to RegisterResult (async.fs: 1004)

But I may well have missed the point you're trying to make.

Happy to apply your summary assuming all the above tallies with your understanding/intent.

async { return 1 } |> Async.RunSynchronously   // also runs inline -- not a threadpool guarantee

• cross-ref to RunSynchronously here implies a threadpool guarantee it doesn't provide

- /// <p>Does not ensure execution takes place on a threadpool thread; see
- /// <see cref="M:Microsoft.FSharp.Control.FSharpAsync.RunSynchronously`1"/> or
- /// <see cref="M:Microsoft.FSharp.Control.FSharpAsync.SwitchToThreadPool"/> if this is required.</p>
+ /// <p>Does not ensure execution takes place on a threadpool thread; see
+ /// <see cref="M:Microsoft.FSharp.Control.FSharpAsync.SwitchToThreadPool"/> if this is required.</p>

The key driver for me referring to both was to try to explain the key behavioral difference of consequence between RS and RSI in terms of other concrete methods as a pedagogical mechanism.

AIUI (but I may very well be wrong) RunSynchronously does provide this guarantee, as which:

1. stays on current thread until the first asynchronous suspension if all these things are true:

• the current thread is a threadpool thread
• and SynchronizationContext.Current is null
• and we're not trying to apply a timeout

2. in all other cases it posts the work into the thread pool and uses the calling thread to await

Note I renamed the internal impl to RunSynchronouslyBackgroundThreadPool to try to convey the above semantics in shorthand.

All of that said, clearly my wording didn't get the point across as intended.

Hence I feel it may make more sense to reword it and/or remove it entirely as the proposed change turns it into a non-sequitur as the sentence no longer enables people to triangulate/bridge the concepts as intended?