class Dispatcher

no copy, no move (at least for now)

True iff the caller is running under this dispatcher.

async::Loop -> if caller is running on the async::Loop's one thread

fdf::SynchronizedDispatcher -> fdf::Dispatcher::GetCurrent() matches this

Dispatcher's impl.

The caller can post tasks to this dispatcher, but should use ClosureQueue

or similar to ensure that the tasks won't touch anything that's already

gone.

This tells the dispatcher to stop running tasks after any currently-running

task. Any pending tasks are deleted at some time between when this call

starts and when Join() completes.

This can be called on any thread, including the Dispatcher's only/current

thread (in which case no further work beyond the currently-running

task/callback will run on the Dispatcher).

Join must not be called on the Dispatcher thread.

This is only allowed to be called when the caller knows (via

caller-specific means) that no currently-running task on the Dispatcher

will block (for any significant duration on anything other than a quick

lock or quick futex), and that no currently-running task will wait for the

current thread.

Returns when there isn't any currently-executing task, all pending tasks

have been deleted, and any uniquely-owned thread (if any) has completed.

The caller requirements above are satisfied by CodecImpl callers because

all of the following are true:

* StreamControl will stop blocking thanks to actions taken near top of

CodecImpl::UnbindLocked which happens before Join().

* CoreCodecStopStream() is quick even if the HW can't be told to

immediately cancel a current frame (in DFv2, the need to wait on HW is

deferred until async PrepareStop handling).

* When sharing the fidl thread for core codec processing, clients of

CodecImpl use CodecImpl::UnbindAsync before ~CodecImpl, which means the

Join() happens after StreamControl is done with any blocking on the

shared fidl thread (also the thread which calls Join).

If async::Loop had notification of async::Loop::Quit completion instead of

requiring the caller to call async::Loop::Shutdown and

async::Loop::JoinThreads which will synchronously wait, we'd have an async

mechanism here as well (analogous to fdf::Dispatcher::ShutdownAsync).

However, that wouldn't really eliminate much of the stuff referenced in the

list above, since we'd still want StreamControl to be reasonably quick

about stopping and deleting to avoid delays closing the StreamControl

server end.

DFv1 only, DispatcherViaAsyncLoop only. DispatcherViaFdfDispatcher returns

nullopt. This is only here to allow for fallback to

CoreCodecSetStreamControlProfile when CoreCodecGetSchedulerProfileName

returns empty string.