class WireWeakOnewayBufferClientImpl

Allocates a BufferCollection on behalf of a single client (aka initiator)

who is also the only participant (from the point of view of sysmem).

This call exists mainly for temp/testing purposes. This call skips the

BufferCollectionToken stage, so there's no way to allow another

participant to specify its constraints.

Real clients are encouraged to use AllocateSharedCollection() instead,

and to let relevant participants directly convey their own constraints to

sysmem.

`collection_request` is the server end of the BufferCollection FIDL

channel. The client can call SetConstraints() and then

WaitForBuffersAllocated() on the client end of this channel to specify

constraints and then determine success/failure and get the

BufferCollectionInfo_2 for the BufferCollection. The client should also

keep the client end of this channel open while using the

BufferCollection, and should notice when this channel closes and stop

using the BufferCollection ASAP.

Caller provides the backing storage for FIDL message.

Creates a logical BufferCollectionToken which can be shared among

participants (using BufferCollectionToken.Duplicate()), and then

converted into a BufferCollection using BindSharedCollection().

Success/failure to populate the BufferCollection with buffers is

determined via the BufferCollection interface.

Caller provides the backing storage for FIDL message.

Convert a BufferCollectionToken into a connection to the logical

BufferCollection. The BufferCollection hasn't yet been populated with

buffers - the participant must first also send SetConstraints() via the

client end of buffer_collection.

All BufferCollectionToken(s) duplicated from a logical

BufferCollectionToken created via AllocateSharedCollection() must be

turned in via BindSharedCollection() before the logical BufferCollection

will be populated with buffers.

`token` the client endpoint of a channel whose server end was sent to

sysmem using AllocateSharedCollection or whose server end was sent to

sysmem using BufferCollectionToken.Duplicate(). The token is being

"exchanged" for a channel to the logical BufferCollection.

`buffer_collection_request` the server end of a BufferCollection

channel. The sender retains the client end as usual. The

BufferCollection channel is a single participant's connection to the

logical BufferCollection. There typically will be other participants

with their own BufferCollection channel to the logical BufferCollection.

Caller provides the backing storage for FIDL message.

Set information about the current client that can be used by sysmem to

help debug leaking memory and hangs waiting for constraints. |name| can

be an arbitrary string, but the current process name (see

fsl::GetCurrentProcessName()) is a good default. |id| can be an

arbitrary id, but the current process ID (see

fsl::GetCurrentProcessKoid()) is a good default.

This information is propagated to all BufferCollections created using

BindSharedCollection() or AllocateNonSharedCollection() from this

allocator. It does not affect BufferCollectionTokens, since they are

often passed cross-process and should have their names managed manually.

Caller provides the backing storage for FIDL message.

This allows creating a sysmem2 `Allocator` given a sysmem(1)

`Allocator`.

This is mainly useful in situations where library code is handed a

sysmem(1) allocator, but the library code has been updated to use

sysmem2. Typically the library will provide a way to pass in a sysmem2

`Allocator` instead, but client code isn't always in the same repo, so

this message allows the library to still accept the sysmem(1) Allocator

temporarily.

The info set via `SetDebugClientInfo` (if any) is copied to the sysmem2

`Allocator`.

Caller provides the backing storage for FIDL message.