Lines Matching refs:blocking
18 also have the ability to operate in “blocking” mode.
30 - We want to support both blocking and non-blocking semantics
33 - In the case of non-blocking applications, it must be possible
59 Note that the discussion in this document primarily concerns usage of blocking
60 vs. non-blocking I/O in the interface between the QUIC implementation and an
63 libssl, which will support both blocking and non-blocking I/O.
68 The above constraints make it effectively a requirement that non-blocking I/O be
70 first consider how QUIC might be implemented using blocking network I/O
73 To function correctly and provide blocking semantics at the application level,
86 configured in blocking mode or not.
88 While in principle APIs such as select(3) can be used with a socket in blocking
89 mode, this is not an advisable usage mode. If a socket is in blocking mode,
122 trying to implement QUIC on top of blocking I/O in this way would require
128 Another conceptual possibility is that blocking calls could be kept ongoing in
131 - a thread which exists solely to execute blocking calls to the `BIO_write` of
133 - a thread which exists solely to execute blocking calls to the `BIO_read` of an
147 able to support blocking semantics at the application level. Applications
148 which require blocking semantics would only be able to function in thread
150 desired, our APIs would only be usable in a non-blocking fashion.
161 - By blocking in `BIO_write` calls, this precludes correct implementation of
169 aligns optimally to non-blocking I/O and which cannot be accommodated
170 by blocking I/O.
181 seem to be solvable. If parallel threads are blocked in blocking `BIO_read`
192 to be far more disruptive than configuring the socket into non-blocking mode).
203 accommodating applications using custom network BIOs in a blocking mode, these
206 applications implementing their own custom BIOs will do so in a blocking mode.
208 ### Use of non-blocking I/O
210 By comparison, use of non-blocking I/O and select(3) or similar APIs on the
216 highly unlikely that any QUIC implementations exist which use blocking network
220 Note that this is orthogonal to whether we provide blocking I/O semantics to the
221 application. We can use blocking I/O internally while using this to provide
222 either blocking or non-blocking semantics to the application, based on what the
226 non-blocking mode. Though some OSes support a `MSG_DONTWAIT` flag which allows a
227 single I/O operation to be made non-blocking, not all OSes support this (e.g.
229 socket FD we use into non-blocking mode.
231 Of the approaches outlined in this document, the use of non-blocking I/O has the
249 BIOs, and therefore perform blocking I/O on top of any custom BIO.
252 supported blocking semantics, a sophisticated application could if it
253 wished choose to implement a custom blocking memory BIO and implement a
258 (It is worth noting also that the implementation of blocking semantics at
261 build blocking semantics out of a non-blocking QUIC instance; this is not
265 - Configuring a socket into non-blocking mode might confuse an application.
280 non-blocking mode, it would need to be trying to use the socket in some
295 sockets in blocking mode anyway.
301 - An application retains full control of its event loop in non-blocking mode.
303 When using libssl in application-level blocking mode, via a custom poller
305 over I/O than it actually is at present when using libssl in blocking mode.
310 - Does not rely on creating threads and can support blocking I/O at the
318 blocking application-level I/O on top of a on a custom memory-based BIO
320 than the current TLS stack, which cannot be used in blocking mode when used
332 non-blocking I/O internally. Applications can use blocking or non-blocking I/O
333 at the libssl API level. Network-level BIOs must operate in a non-blocking mode
346 application event loop in application-level non-blocking mode by exposing an
492 Traditionally an SSL object has operated either in blocking mode or non-blocking
495 no issue. Since the QUIC implementation is building on non-blocking I/O, this
496 implicit configuration of non-blocking mode is not feasible.
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.
504 non-blocking mode:
507 int SSL_set_blocking_mode(SSL *s, int blocking);
511 Applications desiring non-blocking operation will need to call this API to
514 simpler for blocking applications, which are likely to be seeking a simpler
515 solution. However, blocking mode cannot be supported with a non-pollable BIO,
516 and thus blocking mode defaults to off when used with such a BIO.
521 non-blocking; for a memory-based BIO it is a no-op; for `BIO_s_ssl` it is
526 When blocking mode is configured, the QUIC implementation will call
535 read and write BIOs, blocking mode cannot be enabled and blocking mode defaults
