class CodecImpl

The CodecImpl will take care of doing set_error_handler() on the sysmem

connection. The sysmem connection should be set up to use the

shared_fidl_dispatcher.

This is only intended for use by LocalCodecFactory in creating the

appropriate CodecAdapter.

The LocalCodecFactory optionally calls this method between construction and

SetCoreCodecAdapter(). If this method is not called, CodecImpl will treat

any call to onCoreCodecLogEvent() as a nop, and will not require that the

CodecAdapter sub-class implement CoreCodecMetricsImplementation().

The LocalCodecFactory calls this method once just after CodecImpl

construction and just before BindAsync().

There's only one CodecAdapter for the lifetime of the CodecImpl. This

mechanism intentionally doesn't permit switching input format to a

completely different format, and a CodecAdapter is free to reject any

format change it wants to reject. Before giving up, a client that uses

per-stream input format overrides should go around one more time with a

freshly created Codec created directly with the new format if the client

gets a Codec failure having overridden the input format on a stream of a

Codec such that the stream's input format doesn't exactly match the Codec's

input format (at least for now).

The LocalCodecFactory optionally calls this method after SetCoreCodecAdapter() and before

CoreCodecInit(). This method is a passthrough to the underlying

CodecAdapter::SetCodecDiagnostics() method. Not that the codec does not retain any ownership

of the CodecDiagnostics. The pointer is guaranteed to live longer than the codec_impl and if

this method is called, the pointer will not be nullptr.

BindAsync()

This enables serving Codec (soon).

Must be called on shared_fidl_thread.

It remains permitted to cause ~CodecImpl (on shared_fidl_thread) after this

call.

The core codec initialization and actual binding occur shortly later async

after the start of this call, possibly after this call has returned. This

is to avoid core codec initialization slowing down the shared_fidl_thread()

which may be handling other stream data for a different CodecImpl instance.

Any error, including those encountered before binding is fully complete,

will call error_handler on a clean stack on shared_fidl_thread(), after

this call (also on shared_fidl_thread()) returns. If the client code runs

~CodecImpl on shared_fidl_thread instead (before error_handler has run on

shared_fidl_thread), the error_handler will be deleted without being run.

The error_handler is expected to trigger ~CodecImpl to run, either

synchronously during error_handler(), or shortly after async. In other

words it's the responsibility of client code to delete the CodecImpl in a

timely manner during or soon after error_handler(). Until ~CodecImpl, the

CodecAdmission won't be released, and the channel itself won't be closed

(intentionally, to ensure the old instance is cleaned up before a new

instance is created based on a client retry triggered by server channel

closure).

Codec interface

This way CodecBuffer doesn't use the core_codec_bti_ directly.

Complain sync, then Unbind() async. Even if more than one caller

complains, the async Unbind() work will only run once (but in such cases it

can be nice to see all the complaining in case multiple things fail at

once). While more than one source of failure can complain, only one will

actually trigger Unbind() work, and the rest will just return knowing that

Unbind() work is started. The Unbind() work itself will synchronize such

that other-thread sources of failure are no longer possible (can no longer

even complain) before deallocating "this".

Callers to Fail() must not be holding lock_. On return from Fail(), "this"

must not be touched as it can already be deallocated.

Callers to FailLocked() must hold lock_ during the call. On return from

FailLocked(), the caller can know that "this" is still allocated only up

to the point where the caller releases lock_. Callers are encouraged not

to touch "this" after the call to FailLocked() besides releasing lock_,

for consistency with how Fail() is used; that said, the unlock itself is

safe.

Report a devhost-fatal error. This method never returns - instead we

fault the whole process. This should only be used in cases where we

don't really expect an error, and where a client can't unilaterally induce

the error - but in case the error happens despite not being expected, we

want nice output that's easy to debug.