Receiving Requirements

When the producer and consumer specify their synchronization requirements, the other endpoints receive a NvSciStreamEventType_WaiterAttr event. NvSciStreamBlockElementWaiterAttrGet() is operational on the endpoints receiving the event.

NvSciError
NvSciStreamBlockElementWaiterAttrGet(
    NvSciStreamBlock   const block,
    Uint32_t           const elemIndex,
    NvSciSyncAttrList* const waitSyncAttrList
)

If NvSciStreamBlockElementWaiterAttrGet() sets the output parameter to NULL, the element referenced by elemIndex synchronization objects cannot be used to coordinate with the other endpoint. The application must not allocate synchronization objects for the element. This case is rare, but producer and consumer application components designed to be fully modular must recognize and handle this situation.

Otherwise, the output parameter waitSyncAttrList is set to a synchronization attribute list handle. Ownership of this handle belongs to the application calling the function, and it must free the handle when it is no longer needed. The attributes in this list may not exactly match those specified by the originating endpoint. For more than one consumer, the stream combines their requirements into a single attribute list for the element. The stream itself may also perform transformations on the attributes to handle cross-process or cross-system cases.

The application must merge these wait requirements with its own signal requirements to form the final reconciled synchronization attribute list for the element. It can then use the final list to allocate a synchronization object from NvSciSync. A synchronization object is allocated per asynchronous element. The application must map these synchronization objects into the drivers and use them to generate fences passed into the stream.

After receiving all the sync attribute lists they care about, the endpoint applications call the NvSciStreamBlockSetupStatusSet function with a value of NvSciStreamSetup_WaiterAttrImport.