Lines Matching refs:not
50 datagram semantics. These changes are not minor, but there is no way around this
86 configured in blocking mode or not.
89 mode, this is not an advisable usage mode. If a socket is in blocking mode,
96 writeability should guarantee that a subsequent send(3) or recv(3) call will not
102 - The fact that a socket is writeable does not necessarily mean that a datagram
111 Moreover, our QUIC implementation will not drive the Berkeley sockets API
113 then compounded by the limitations of our existing BIO interfaces. We do not
118 guarantee (under a non-buggy OS) that a single syscall will not block, however
121 system call (or any system call), so this does not work either. Therefore,
123 violating the BIO abstraction layer, and would not work with custom BIOs (even
138 `BIO_write` calls do not take an excessive amount of time.
149 assisted mode. In environments where threading support is not available or
152 - Several threads are spawned which the application is not in control of.
172 - Since existing custom BIOs will not be expecting concurrent `BIO_read` and
175 calls obviously does not work since both of these calls must be able to block
178 Moreover, this does not appear to be a realistically implementable approach:
180 - The question is posed of how to handle connection teardown, which does not
184 tear down the connection. However, the BIO interface does not provide
194 Moreover, it is not workable anyway because it only works for a socket-based
195 BIO and violates the BIO abstraction. For BIOs in general, there does not
227 single I/O operation to be made non-blocking, not all OSes support this (e.g.
242 non-`no-sock` builds, so this does not appear to raise any portability
259 the application level also does not rely on any privileged access to the
261 build blocking semantics out of a non-blocking QUIC instance; this is not
281 way. But it is not possible for an application to pass a socket to our
283 QUIC still work. Using QUIC necessarily requires that an application not
291 simply sharing a network socket, as incoming datagrams will not be routed
293 coordinated but this is not for MVP.) Thus this also is not a concern.
310 - Does not rely on creating threads and can support blocking I/O at the
313 - Does not require an application-provided network-side custom BIO to be
340 We need to support not just socket FDs but arbitrary BIOs as the basis for the
365 such as `BIO_dgram_pair` which do not naturally correspond to any OS primitive
387 unification is not necessarily significant.
390 they can be used with the generic Win32 `WaitForSingleObject()` API, but not in
391 a useful manner; the generic readiness mechanism for WIndows handles is not
447 libssl will not know how to poll custom poll descriptors itself, thus these are
474 This is not hard as our internal TX record layer allows arbitrary buffering.
496 implicit configuration of non-blocking mode is not feasible.
498 Note that Windows does not have an API for determining whether a socket is in
499 blocking mode, so it is not possible to use the initial state of an underlying
500 socket to determine if the application wants to use non-blocking I/O or not.
519 that it must not block. The SSL object will call this function when it is
534 `BIO_get[rw]poll_descriptor` is not implemented for either of the underlying
