val connect :
?interrupt:unit Async.Deferred.t ->
?timeout:Core.Time_ns.Span.t ->
Config.Client.t ->
'socket Async.Tcp.Where_to_connect.t ->
(([ `Active ], 'socket) Async.Socket.t
* Connection.t
* Async.Reader.t
* Async.Writer.t)
Async.Deferred.tPrefer calling with_connection. This is provided for completeness and backwards compatibility. You must handle closing the Reader.t and Writer.t returned by connect yourself.
val wrap_client_connection_and_stay_open :
Config.Client.t ->
Async.Reader.t ->
Async.Writer.t ->
f:
(Connection.t ->
Async.Reader.t ->
Async.Writer.t ->
('res * [ `Do_not_close_until of unit Async.Deferred.t ])
Async.Deferred.t) ->
('res * [ `Connection_closed of unit Async.Deferred.t ]) Async.Deferred.twrap_client_connection will immediately tear down the connection as soon as f returns. This doesn't accommodate cases where 'res contains more Async primitives, such as a Pipe.Reader.t. wrap_client_connection_and_stay_open gives callers the agency to control when this teardown occurs.
Callers must ensure that `Do_not_close_until becomes determined to avoid leaking file descriptors. The unit Deferred.t returned in `Do_not_close_until is also returned in `Connection_closed in case functions external to wrap_client_connection_and_stay_open care whether the TLS session has been torn down.
It is an error to access the Reader.t/Writer.t once `Do_not_close_until has become determined (doing so may result in weird IO errors).