Lines Matching full:application
16 - The application must have the ability to be in control of the event loop
17 without requiring callbacks to process the various events. An application must
31 for application use of the libssl APIs.
34 for an application to do its own polling and make its own event
62 network. This is independent of and orthogonal to the application interface to
73 To function correctly and provide blocking semantics at the application level,
147 able to support blocking semantics at the application level. Applications
152 - Several threads are spawned which the application is not in control of.
153 This undermines our general approach of providing the application with control
154 over OpenSSL's use of resources, such as allowing the application to do its
158 means if an application opens many outgoing connections, there will need
191 returns. This obviously is a highly application-visible change (and is likely
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
223 application requests.
246 allows an application to provide its own implementation of a
248 powerful and would allow the application to implement its own pollable
252 supported blocking semantics, a sophisticated application could if it
259 the application level also does not rely on any privileged access to the
260 internals of the QUIC implementation and an application could if it wished
263 there should be no need for an application to do so.)
265 - Configuring a socket into non-blocking mode might confuse an application.
276 Of course, application impacts and migration guidance can (and will) all
279 - In order for an application to be confused by us putting a socket into
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
286 - There are some circumstances where an application might want to multiplex
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
304 interface, the application would actually be able to exercise more control
311 application level without relying on thread assisted mode.
313 - Does not require an application-provided network-side custom BIO to be
317 modes of polling in the future (e.g. an application could even building
318 blocking application-level I/O on top of a on a custom memory-based BIO
343 must be reconciled with the desire to support application-managed event loops.
346 application event loop in application-level non-blocking mode by exposing an
347 appropriate OS-level synchronisation primitive to the application. On \*NIX
348 platforms, this essentially means we provide the application with:
354 (potentially) advanced meaningfully, and the application is expected to reenter
367 application-provided custom BIO.
443 reserved for application-defined use. The `value.custom` field of the
445 their choice in. An application is free to define the semantics.
448 only useful when the application will provide a custom poller function, which
460 Where we are provided with a non-pollable BIO, we cannot provide the application
462 application will handle its own network I/O, for example via a
466 fails, indicating that a non-pollable BIO is being used. Thus, if an application
476 application stream data) applies a limit; then calls to e.g. `SSL_write` we
486 which is pollable, for example using condition variables. An application could
500 socket to determine if the application wants to use non-blocking I/O or not.