[erlang-questions] Async ssl_accept, ssl:close, gen_tcp:send and ssl:send
Thu Jul 4 22:50:48 CEST 2013
Again for the list, and now back to my vacation.
---------- Forwarded message ----------
From: Ingela Andin <ingela.andin@REDACTED>
Subject: Re: [erlang-questions] Async ssl_accept, ssl:close, gen_tcp:send
To: Loïc Hoguin <essen@REDACTED>
2013/6/29 Loïc Hoguin <essen@REDACTED>
> I'd like to start a discussion on making additions to the gen_tcp and ssl
> API to allow it to handle more asynchronous operations. The reasons for
> allowing them async are as follow:
> * async ssl_accept: This call can take a long time because there's a few
> round trips between the two endpoints to perform the handshake. Therefore
> there's a lot of waiting going on, not just busy operations. It could be
> more interesting to not block a process for this because the process could
> for example initialize the state for the connection while it waits for the
> handshake to be completed, reducing the latency of applications.
Is it not enough that ssl:transport_accept and ssl:ssl_accept can/should be
called by different processes?
> * async ssl:close: This call can also take a long time for similar
> reasons. I think the same can apply to gen_tcp? Anyway if you have a long
> running process that holds a connection at some point, and wants to close
> it, it might interrupt its normal workflow. A temporary solution would be
> to have a process dedicated to closing these sockets and pass it ownership,
> but if that can be avoided...
> * async send: Send also blocks, I suppose because it waits for the TCP
> ack before returning. Sometimes you don't have the luxury to wait, so it
> would be good to have an alternative documented solution. An undocumented
> solution can be found here: http://www.erlang-factory.com/**
I will not go in to the other points now, as I am supposed to be on
vacation, so I will go back to that!
Regards Ingela Erlang/OTP team - Ericsson AB
I'm mostly interested in the first point, as this is something that doesn't
> really have solutions. I could help with implementing or testing it if
> there is interest.
> There could also be an async TCP accept I suppose, except I already looked
> into adding that and the current code doesn't allow it easily. And I don't
> need it anymore, but perhaps someone does.
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions