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

[Ingela Andin]

Again for the list, and now back to my vacation.


---------- Forwarded message ----------
From: Ingela Andin <ingela.andin@REDACTED>
Date: 2013/7/3
Subject: Re: [erlang-questions] Async ssl_accept, ssl:close, gen_tcp:send
and ssl:send
To: Loïc Hoguin <essen@REDACTED>


Hi!


2013/6/29 Loïc Hoguin <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?



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



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.
>
> Thanks.
>
> --
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
> ______________________________**_________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130704/c8238f23/attachment.htm>