[erlang-questions] Async ssl_accept, ssl:close, gen_tcp:send and ssl:send

[Loïc Hoguin]

Hey Ingela,

On 07/04/2013 10:50 PM, Ingela Andin wrote:
> 2013/6/29 Loïc Hoguin <essen@REDACTED <mailto:essen@REDACTED>>
>
>     Hello,
>
>     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?

Problem comes when trying to guarantee that ssl_accept will be ran 
before any reading is done. If we can have ssl_accept ran asynchronously 
the message order guarantees this with no extra work and without 
blocking any process.

If the async ssl_accept fails, I'm more than fine finding out about it 
when trying to read right after.

>       *  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...

Same for this really. We don't really care to know that the socket is 
closed properly most of the time. We just want to close it and free 
resources and move on.

>       *  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/__conference/SFBay2013/speakers/__GeoffCant
>     <http://www.erlang-factory.com/conference/SFBay2013/speakers/GeoffCant>

This one is unrelated and not problematic per se but would also be 
pretty cool to have.

> 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!

I hope you had a great time!

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu