You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A bounded wait answers with one of three values and no others
⚠️⚠️ MEASURED TWICE, THE SECOND TIME ONLY UNDER WINE, WHICH IS WHAT MADE
THE SHAPE VISIBLE. `kal_timeout_read' upon the standard input reported an
error belonging to the RESOURCE where the interface defines a set for the
WAIT: first `kal_err_invalid' for a handle of zero, then whatever
`PeekNamedPipe' or `WSAPoll' had failed with. The conformance suite
reported "a bounded read reports success, an expiry, or a refusal" as not
holding both times, and the second time on one runner out of three ---
which is to say, only where the system chose a different error for the
same condition.
⇒ `await_stream' now answers with `kal_ok', `kal_err_again' or
`kal_err_not_supported' and nothing else. An error belonging to the
resource is the TRANSFER's to report, and the transfer follows the wait.
⭐ AND THE REAL ERROR IS KEPT WHERE THE RESOURCE IS KNOWN.
`kal_timeout_accept' and `kal_timeout_recv_from' are reached with a
socket this implementation made, so a failure there carries information a
caller can act upon; the narrowing happens only on the path that takes a
caller's stream, where the resource is not known.
⚠️ `is_socket' also stops depending on WHICH error a system reports for a
handle that is not a socket. It read "it is a socket unless the failure
was WSAENOTSOCK", and Wine does not choose the same value. Every socket
this implementation hands out has been connected, bound or accepted, so
`getsockname' succeeds upon all of them; the test is that it succeeds.
0 commit comments