[erlang-questions] Do you wanna play with enif_select?

[Sverker Eriksson]

The connect in sverk_tcp is blocking (for no reason)
but the send and receive ops are non-blocking using enif_select()
when the socket buffers gets full/empty.


To fix the connect move up SET_NONBLOCKING(sock) before connect()
then catch the EINPROGRESS from connect
and call enif_select(.., ERL_NIF_SELECT_WRITE, ..)
return to Erlang and wait for read_output message
and then call some continue_connect_nif for example.


I did some runs on the loopback and it looked promising,
almost twice the throughput if I remember correctly.
But, sverk_tcp is a very stripped down implementation
without all the features that gen_tcp provides, so I wouldn't
get overly excited about that.


You can compare yourself with

ts:run(kernel, netmarks_SUITE, sverk_tcp).
vs
ts:run(kernel, netmarks_SUITE, gen_tcp).


/Sverker


On 12/02/2016 04:47 PM, Vans S wrote:
> The title intrigued me.
>
> On line 148 of lib/kernel/test/netmarks_SUITE_data/sverk_tcp.c
>
> +   cret = connect(sock, ai->ai_addr, ai->ai_addrlen);
>
> Any idea what a good way would be to make this a non-blocking connect.
> We obv want to avoid callback spaghetti in erlang, but we also want to avoid blocking
> in the nifs?
>
> Im thinking a try_connect select recursion func on the erlang side?
>
> Or would blocking on the connect there in the NIF be fine now and not throw off the scheduler?
>
> I noticed some files commited that are called after benchmark suites.  Any results of how performance fairs compared
> to the built in net-io lib?
>
>
>
> On Friday, December 2, 2016 10:22 AM, Sverker Eriksson <sverker.eriksson@REDACTED> wrote:
> https://github.com/erlang/otp/pull/1264
>
>
> This PR is introducing a new feature enif_select() as a way for
> NIFs to ask for asynchronous notification when a file descriptor
> (a socket for example) is ready for (more) reading or writing.
>
> The API is not carved in stone yet and we would like some feedback.
> So please, take enif_select for a spin and share your thoughts.
>
> /Sverker, Erlang/OTP @ Ericsson
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>