Proposal: add MailboxProcessor.StartWith method

[xloggr]

MailboxProcessor (MP) provides a convenient mechanism to implement message loops. I sometimes use it in console apps to implement the main application loop, which starts the MP and then waits until MP "pumps" all messages. Since the main thread has nothing else to do, I would like it to run the MP synchronously. Unfortunately MP does not provide an equivalent of Async.RunSynchronously function.

There are other cases where it'd make sense to run MP in the current thread or a specific execution context. e.g. when using it in a worker thread. While simulating synchronous invocation is easy, e.g. by calling PostAndReply, the computation itself is always forced to run on the thread pool, introducing an unnecessary overhead.

This behavior is due to the MailboxProcessor.Start method directly calling Async.Start. As a result the caller has no control over computation execution context. (Well, it's possible to control it using Async.SwitchTo*(...) within the computation, but it'd complicate the code)

One simple way to make MP more flexible is to add MailboxProcessor.StartWith method accepting async computation "starter" function as a parameter.

Specifically, in the MP type definition, change

member x.Start() =
  ...
  Async.Start(computation=p, cancellationToken=cancellationToken)

to

member x.StartWith(startAsync: Async<unit> -> CancellationToken -> unit) =
  ...
  startAsync p cancellationToken

and then reimplement the original Start method as follows:

member x.Start() = x.StartWith (fun c ct -> Async.Start(computation=c, cancellationToken=ct))

It will then be possible to call the new method with Async.Start, Async.RunSynchronously, or any other function having an appropriate signature:

// run on the thread pool - mimic the current implementation
mbox.StartWith (fun c ct -> Async.Start(computation=c, cancellationToken=ct))
// start on the current thread
mbox.StartWith (fun c ct -> Async.StartImmediate(computation=c, cancellationToken=ct))
// run synchronously
mbox.StartWith (fun c ct -> Async.RunSynchronously(computation=c, cancellationToken=ct))
// run in a user-specified context
mbox.StartWith customAsyncStarter
...

Also, the following convenience member can be added to the class, to complement the static member Start(...):

static member StartWith(body, startAsync, ?cancellationToken) =
    let mailboxProcessor = new MailboxProcessor<'Msg>(body, ?cancellationToken=cancellationToken)
    mailboxProcessor.StartWith(startAsync)
    mailboxProcessor

As you can see, the proposed change is fairly small, fully backward-compatible, makes MailboxProcessor more flexible and, hopefully, usable in more contexts. If you find it acceptable, I will be glad to send a PR implementing the change.

[cartermp]

We wouldn't accept a rename of any API because that would be a breaking change. But if you send a draft PR of the kind of thing you're after, with some additional info about the changes, we'll certainly take a look.

[xloggr]

I'm afraid I was not clear enough in my proposal. Please let me reiterate:

• The change is fully backward-compatible.
• I'm not proposing renaming any existing APIs or changing semantics of any existing methods.

The nature of the change is parametrizing hard-coded call to Async.Start, so that the callers can specify alternative async starters. The original behavior of MailboxProcessor.Start is preserved, for both instance and static methods. The change is quite small and easily verifiable - just a few lines of code in a single file. To remove any doubt I rephrased my initial post, removing the word "rename" altogether.

I created PR #11417 to demonstrate the change.

[dsyme]

Could you add this at fslang-discussions please?

[dsyme]

Is there any reason not to prefer just adding mbox.StartImmediate and mbox.RunSynchronously? That would avoid the function parameter

[xloggr]

As requested, added to the fslang-discussions as the issue #997.

[xloggr]

@dsyme , to answer your question

Is there any reason not to prefer just adding mbox.StartImmediate and mbox.RunSynchronously? That would avoid the function parameter

I see a number of reasons:

1. I believe libraries should be generic, leaving choices like this to the library users. In this case developers should be able to choose in which threading context to start a MailboxProcessor rather than being limited by the library.

2. MailboxProcessor core type could have been independent on Async module methods, only depending on the Async<_> type. In the future more Async.Start... methods can be added and you wouldn't want to keep up with the Async module changes in the MailboxProcessor. Besides, exposing "async starter" as a parameter enables using custom implementations, not necessarily originating from the Async module.

3. I consider StartWith as a core type method, while methods like Start, StartImmediate, and RunSynchronously - as extension methods that can be introduced for convenience. They are useful, but since they don't require accessing class private data, they belong to a type extension rather than the core type definition.

Here is a code snippet explaining the last point:

// core type definition
type MailboxProcessor... =
  member x.StartWith(asyncStarter) = ...

// type extension - convenience methods
type MailboxProcessor with
  member x.Start() = x.StartWith((fun c ct -> Async.Start(computation=c, CancellationToken=ct)))
  member x.StartImmediate() = x.StartWith((fun c ct -> Async.StartImmediate(computation=c, CancellationToken=ct)))
  member x.RunSynchronously() = x.StartWith((fun c ct -> Async.RunSynchronously(computation=c, CancellationToken=ct)))
  // etc

MailboxProcessor.Start is required for the backward compatibility so it appears in the core type. If you feel there's a value in having additional extension methods, introducing a MailboxProcessor type extension would be an option.

[dsyme]

Covered by the lang suggestion

[bmitc]

For reference, StartImmediate was added here #14931.

Here it is in the F# MailboxProcessor documentation.