Internal exception surfacing when calling Post on disposed MailBoxProcessor

[majocha]

Message: 
System.ObjectDisposedException : Cannot access a disposed object.
Object name: 'Microsoft.Win32.SafeHandles.SafeWaitHandle'.

  Stack Trace: 
SafeHandle.DangerousAddRef(Boolean& success)
Kernel32.SetEvent(SafeWaitHandle handle)
EventWaitHandle.Set()
Mailbox`1.Post(TMsg msg) line 193
FSharpMailboxProcessor`1.Post(TMsg message) line 419

I can see the above exception occasionally in this test:

fsharp/tests/FSharp.Core.UnitTests/FSharp.Core/Microsoft.FSharp.Control/MailboxProcessorType.fs

Line 316 in e6854f5

member this.``After dispose is called, mailbox should stop receiving and processing messages``() = task {

I assume the expected behavior here is no exception?

I'll try to come up with consistent minimal repro, but the problem seems to be here:

fsharp/src/FSharp.Core/mailbox.fs

Lines 189 to 193 in 69fa88b

	match pulse with
	| null -> () // no one waiting, leaving the message in the queue is sufficient
	| ev ->
	// someone is waiting on the wait handle
	ev.Set() |> ignore

ev is disposed and Set will fail.

The fix seems to be to also assign null to pulse when disposing it here:

fsharp/src/FSharp.Core/mailbox.fs

Lines 336 to 346 in 69fa88b

	interface System.IDisposable with
	member _.Dispose() =
	lock syncRoot (fun () ->
	if isNotNull inboxStore then
	inboxStore.Clear()
	arrivals.Clear()
	isDisposed <- true)
	if isNotNull pulse then
	(pulse :> IDisposable).Dispose()

[majocha]

This happens with timeouts or cancellation enabled, only then a wait handle is used in Mailbox.

[majocha]

Minimal repro:

open System.Threading

let cts = new CancellationTokenSource()
let mb =
    MailboxProcessor.Start( (fun inbox ->
        async {
            let! _ = inbox.Receive()
            let! _ = inbox.Receive()
            return ()
        }),
        cancellationToken = cts.Token
    )

// ensure pulse gets created
Thread.Sleep 100

mb.Post 1
mb.Dispose()
mb.Post 2

[T-Gro]

Related to https://github.com/dotnet/fsharp/pull/13036/files#diff-89da65b208fb5d835cded7993284e2c562b2d6530cc320cc030f5079dfc0372b possibly?

[T-Gro]

I think getting an ObjectDisposedException is the right scenario if the object was disposed.
But it should be better controlled by Fsharp.Core and not thrown from internal usage.

[majocha]

Related to https://github.com/dotnet/fsharp/pull/13036/files#diff-89da65b208fb5d835cded7993284e2c562b2d6530cc320cc030f5079dfc0372b possibly?

I think the exception happens in a code path that was there before that PR.

I think getting an ObjectDisposedException is the right scenario if the object was disposed. But it should be better controlled by Fsharp.Core and not thrown from internal usage.

This may be a breaking change. It seems the current standard behavior most of the time is waiting indefinitely on a disposed wait handle. Only on rare occasions where the wait handle is disposed while it's not awaited this here bug happens.