86
87
88 The completion of the posted Receive is reported to the Consumer
89 asynchronously through a DTO Completion event based on the
90 configuration of the connection for Solicited Wait and the specified
91 completion_flags value for the matching Send. The value of
92 DAT_COMPLETION _UNSIGNALLED_FLAG is only valid if the Endpoint Recv
93 Completion Flags DAT_COMPLETION_UNSIGNALLED_FLAG. Otherwise,
94 DAT_INVALID_PARAMETER is returned.
95
96
97 A Consumer must not modify the local_iov or its content until the DTO
98 is completed. When a Consumer does not adhere to this rule, the
99 behavior of the Provider and the underlying Transport is not defined.
100 Providers that allow Consumers to get ownership of the local_iov but
101 not the memory it specified back after the dat_ep_post_recv() returns
102 should document this behavior and also specify its support in Provider
103 attributes. This behavior allows Consumer full control of the local_iov
104 content after dat_ep_post_recv() returns. Because this behavior is not
105 guaranteed by all Providers, portable Consumers should not rely on this
106 behavior. Consumers shouldnot rely on the Provider copying local_iov
107 information.
108
109
110 The DAT_SUCCESS return of the dat_ep_post_recv() is at least the
111 equivalent of posting a Receive operation directly by native Transport.
112 Providers should avoid resource allocation as part of
113 dat_ep_post_recv() to ensure that this operation is nonblocking and
114 thread safe for an UpCall.
115
116
117 If the size of an incoming message is larger than the size of the
118 local_iov, the reported status of the posted Receive DTO in the
119 corresponding Completion DTO event is DAT_DTO_LENGTH_ERROR. If the
120 reported status of the Completion DTO event corresponding to the posted
121 Receive DTO is not DAT_DTO_SUCCESS, the content of the local_iov is not
122 defined.
123
124
125 The operation is valid for all states of the Endpoint. The actual data
126 transfer does not take place until the Endpoint is in the
|
86
87
88 The completion of the posted Receive is reported to the Consumer
89 asynchronously through a DTO Completion event based on the
90 configuration of the connection for Solicited Wait and the specified
91 completion_flags value for the matching Send. The value of
92 DAT_COMPLETION _UNSIGNALLED_FLAG is only valid if the Endpoint Recv
93 Completion Flags DAT_COMPLETION_UNSIGNALLED_FLAG. Otherwise,
94 DAT_INVALID_PARAMETER is returned.
95
96
97 A Consumer must not modify the local_iov or its content until the DTO
98 is completed. When a Consumer does not adhere to this rule, the
99 behavior of the Provider and the underlying Transport is not defined.
100 Providers that allow Consumers to get ownership of the local_iov but
101 not the memory it specified back after the dat_ep_post_recv() returns
102 should document this behavior and also specify its support in Provider
103 attributes. This behavior allows Consumer full control of the local_iov
104 content after dat_ep_post_recv() returns. Because this behavior is not
105 guaranteed by all Providers, portable Consumers should not rely on this
106 behavior. Consumers should not rely on the Provider copying local_iov
107 information.
108
109
110 The DAT_SUCCESS return of the dat_ep_post_recv() is at least the
111 equivalent of posting a Receive operation directly by native Transport.
112 Providers should avoid resource allocation as part of
113 dat_ep_post_recv() to ensure that this operation is nonblocking and
114 thread safe for an UpCall.
115
116
117 If the size of an incoming message is larger than the size of the
118 local_iov, the reported status of the posted Receive DTO in the
119 corresponding Completion DTO event is DAT_DTO_LENGTH_ERROR. If the
120 reported status of the Completion DTO event corresponding to the posted
121 Receive DTO is not DAT_DTO_SUCCESS, the content of the local_iov is not
122 defined.
123
124
125 The operation is valid for all states of the Endpoint. The actual data
126 transfer does not take place until the Endpoint is in the
|