Erlang/OTP 21 new IO Polling Framework

I have read a lot of C code from the huge driver inet_drv.c in the goal to understand internal Erlang VM and I think that I did good advances, so I have just confused about the new Erlang/OTP 21 IO Polling framework, and I can’t find any resources to explain it in some of details except the Kenneth Lundin’s conference presentation (.ppt file) in 2017 so :
when data arrives at a socket epolled or kqueued by the IO Poll Thread, what will this last do in fact ?
before Erlang 21 it’s the Schudeler who epoll or kqueue the socket (consider just Kernel Space Polling) and when data arrives, it will map the FD via ports and send signals to ports that results in ready_input driver entry callback function so it’s very clear,
but after Erlang 21 it’s just one IO Poll Thread who will epoll or kqueue sockets and when data arrives what will do ?
1-he just send signal to the Scheduler Thread to wake him from futex and this last will finish the work like before Erlang 21?
2-he will map the FD via ports and send signals to ports directly ?
In Kenneth’s presentation I note the absence of the check_io notation in Erlang 21 draw model, so what exactly is happening here ?
I loved Erlang and I want from my heart to develop my self in mastering this language but the big problem is the absence of documentations about it.

3 Likes

A mix between both happens. The poll thread(s) sends signals to the port/process that subscribed to the I/O event. If the scheduler that is responsible for the port/process is currently sleeping, then it will wake that scheduler by triggering the futex.

Before Erlang/OTP 21, the work done was very similar, only that it was a scheduler that sent the signal to the port/process. In fact, for ports that are in {active, true} mode, the I/O polling work is still done in schedulers and works just as in Erlang/OTP 21.

3 Likes

Thank you it was my thinking too that the IO Poll Thread do mapping from FD to ports in check_io and send signals, but what do you mean please by :
" In fact, for ports that are in {active, true} mode, the I/O polling work is still done in schedulers and works just as in Erlang/OTP 21" ?

2 Likes

1- Okey I tracked prim_inet:setopts(S,[{active, true}]) from scratch, it resulted in triggering sock_select.

2- In the other hand I tracked gen_tcp:recv that should called in order to receive from passive socket ({active, false}) and it results in socket_select too (considering always that there is no ready data in the socket just to trigger IO Polling)

So I can see that in the two cases, Standard IO Polling is triggered and by nature the Poll Thread will do the work and not the Scheduler Thread, so I think you have wrong and just if you can prouve your point of view (basing on the code).

1 Like