<div dir="ltr"><div><br></div><div style>Again for the list, and now back to my vacation.</div><div style><br></div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Ingela Andin</b> <span dir="ltr"><<a href="mailto:ingela.andin@gmail.com">ingela.andin@gmail.com</a>></span><br>
Date: 2013/7/3<br>Subject: Re: [erlang-questions] Async ssl_accept, ssl:close, gen_tcp:send and ssl:send<br>To: Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>><br><br><br><div dir="ltr">Hi!<br>
<div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">2013/6/29 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
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:<br>
<br>
* 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.<br>
<br></blockquote><div><br></div></div><div>Is it not enough that ssl:transport_accept and ssl:ssl_accept can/should be called by different processes? </div><div class="im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* 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...<br>
<br>
* 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: <a href="http://www.erlang-factory.com/conference/SFBay2013/speakers/GeoffCant" target="_blank">http://www.erlang-factory.com/<u></u>conference/SFBay2013/speakers/<u></u>GeoffCant</a></blockquote>
<div><br></div><div><br></div></div><div>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! </div><div><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
Thanks.<span><font color="#888888"><br>
<br>
-- <br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</font></span></blockquote></div></div><br></div></div>
</div><br></div>