class SetDispensable
Defined at line 1085 of file fidling/gen/sdk/fidl/fuchsia.sysmem/fuchsia.sysmem/cpp/fidl/fuchsia.sysmem/cpp/markers.h
A dispensable token can fail after buffers are logically allocated
without causing failure of its parent (if any).
The dispensable token participates in constraints aggregation along with
its parent before logical buffer allocation. If the dispensable token
fails before buffers are logically allocated, the failure propagates to
the dispensable token's parent.
After buffers are logically allocated, failure of the dispensable token
(or any child of the dispensable token) does not propagate to the
dispensable token's parent. Failure does propagate from a normal
child of a dispensable token to the dispensable token. Failure
of a child is blocked from reaching its parent if the child is attached,
or if the child is dispensable and the failure occurred after logical
allocation.
A dispensable token can be used in cases where a participant needs to
provide constraints, but after buffers are allocated, the participant
can fail without causing buffer collection failure from the parent's
point of view.
In contrast, AttachToken() can be used to create a token which does not
participate in constraints aggregation with its parent, and whose
failure at any time does not propagate to its parent, and whose delay
providing constraints does not prevent the parent from completing its
buffer allocation.
An initiator may in some scenarios choose to initially use a dispensable
token for a given instance of a participant, and then later if the first
instance of that participant fails, a new second instance of that
participant my be given a token created with AttachToken().
If a client uses this message, the client should not rely on the
client's own BufferCollectionToken or BufferCollection channel to close
from the server end due to abrupt failure of any BufferCollectionToken
or BufferCollection that the client has SetDispensable() and given out
to another process. For this reason, the client should take extra care
to notice failure of that other process via other means.
While it is possible (and potentially useful) to SetDispensable() on a
direct child of a BufferCollectionTokenGroup, it isn't possible to later
replace a failed dispensable token that was a direct child of a group
with a new token using AttachToken() (since there's no AttachToken() on
a group). Instead, to enable AttachToken() replacement in this case,
create an additional non-dispensable token (node) that's a direct child
of the group and make the existing dispensable token a child of the
additional token (node). This way, the additional token (node) that is
a direct child of the group has BufferCollection.AttachToken() which can
be used to replace the failed dispensable token.
SetDispensable() on an already-dispensable token is idempotent.
Public Members
static const bool kHasClientToServer
static const bool kHasClientToServerBody
static const bool kHasServerToClient
static const bool kHasServerToClientBody
static const bool kHasNonEmptyUserFacingResponse
static const bool kHasDomainError
static const bool kHasFrameworkError
static const uint64_t kOrdinal