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

[Loïc Hoguin]

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.

  *  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/conference/SFBay2013/speakers/GeoffCant

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.

Thanks.

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