template <>
class WireWeakOnewayClientImpl
Defined at line 13723 of file fidling/gen/sdk/fidl/fuchsia.sysmem/fuchsia.sysmem/cpp/fidl/fuchsia.sysmem/cpp/wire_messaging.h
Public Methods
::fidl::OneWayStatus AllocateNonSharedCollection (::fidl::ServerEnd< ::fuchsia_sysmem::BufferCollection> && collection_request)
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.
Allocates 40 bytes of message buffer on the stack. No heap allocation necessary.
::fidl::OneWayStatus AllocateSharedCollection (::fidl::ServerEnd< ::fuchsia_sysmem::BufferCollectionToken> && token_request)
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.
Allocates 40 bytes of message buffer on the stack. No heap allocation necessary.
::fidl::OneWayStatus BindSharedCollection (::fidl::ClientEnd< ::fuchsia_sysmem::BufferCollectionToken> && token, ::fidl::ServerEnd< ::fuchsia_sysmem::BufferCollection> && buffer_collection_request)
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.
Allocates 40 bytes of message buffer on the stack. No heap allocation necessary.
::fidl::OneWayStatus SetDebugClientInfo (::fidl::StringView name, uint64_t id)
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.
Allocates 120 bytes of message buffer on the stack. No heap allocation necessary.
::fidl::OneWayStatus ConnectToSysmem2Allocator (::fidl::ServerEnd< ::fuchsia_sysmem2::Allocator> && allocator_request)
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`.
Allocates 40 bytes of message buffer on the stack. No heap allocation necessary.