我在 Erlang 中有兩種監聽套接字和接受器模型：
- - - - - - 第一的 - - - - - -
-module(listeners).
....
start() ->
{ok, Listen}=gen_tcp:listen(....),
accept(Listen).
%%%%%%%%%%%%%%%%%%%%%
accept(Listen) ->
{ok, Socket}=gen_tcp:accept(Listen),
spawn(fun() ->handle(Socket) end),
accept(Listen).
%%%%%%%%%%%%%%%%%%%%%
handle(Socket) ->
....
- - - - -第二 - - - - -
-module(listener).
....
start() ->
supervisor:start_link({local,?MODULE},?MODULE, []).
%%%%%%%%%%%%%
init([]) ->
{ok, Listen}=gen_tcp:listen(....),
spawn(fun() ->free_acceptors(5) end),
{ok, {{simple_one_for_one, 5,1},[{child,{?MODULE,accept,[Listen]},....}]}.
%%%%%%%%%%%%%
free_acceptors(N) ->
[supervisor:start_child(?MODULE, []) || _ <-lists:seq(1,N)],
ok.
%%%%%%%%%%%%%
accept(Listen) ->
{ok, Socket}=gen_tcp:accept(Listen).
handle(Socket).
%%%%%%%%%%%%%%
handle(Socket) ->
....
第一個代碼很簡單，主行程創建一個監聽套接字并監聽接受新連接，當一個連接到來時，它接受該連接產生一個新行程來處理它并回傳接受其他新連接。
The second code is also simple, the main process creates a supervision tree, the supervisor creates a listen socket and start 5 childs (spawning a new process to run free_acceptors/1 because this function calls the supervisor process and the supervisor is in it's init function and it can't start childs before it's own start so the new process will wait the supervisor until it finishes it's initiation) and give the listen socket as an argument to it's childs, and the five children start listen to accept new coming connections at the SAME time.
So we run the two codes each in a separate machine that have a CPU with a single core and 5 clients try to connect at the same time to the first server and other 5 to the second server: from the first look, i thinked that the second server is faster because all connections will be accepted in parallel and at the same time and in the first code the fivest client will wait the server to accept the precedents four to accept it and so on.
but going deeply at the ERTS, we have a single OS-Thread per core to handle erlang processes and since a Socket is an OS structure then gen_tcp:listen will call OS-Thread:listen (this is just pseudo code to understand) to create an OS Socket and gen_tcp:accept calls OS-Thread:accept to accept new connection and this later can accept just one connection at a time and the fivest client still wait the server to accept the fourth precedents, so is there difference between the two codes ? i hope that you understand me.
Even if the code doesn't include sockets the Erlang processes will be always concurrent and not parallel because there is just one core, but the Sheduler will manage tasks between processes very fast and close to parallel run, so the problem is in the use of sockets that use OS calls across the single OS-Thread.
NOTE : Ejabberd use the first implementation and Cowboy use the second.
uj5u.com熱心網友回復：
在 OS 級別，偵聽套接字關聯了一個等待接受連接的 OS 執行緒佇列，無論該佇列是否有任何 OS 執行緒被阻塞或為空，因為它將以不同的方式處理（忙等待非阻塞接受，選擇，epoll...）。
BEAM 沒有單個作業系統執行緒，即使您在具有單個 CPU 的系統上運行它，它也具有不同型別的作業系統執行緒
關于你的問題，我懷疑，如果有的話，最好讓多個接受者 erlang 執行緒不斷阻塞gen_tcp:accept呼叫，因為這樣 ERTS 就知道愿意接受更多連接的 erlang 代碼（handle(Socket)在你的第二個例子中應該產生一個作業人員或將接受的套接字發送給一個作業人員并回傳接受連接），而在單個接受 - 生成回圈中，此知識是隱藏的。
我對代碼不夠熟悉，無法了解細微差別，但似乎代碼可以很好地處理多個接受，在內部對它們進行排隊，因此擁有多個接受器可能會好一些。
即，在第一個請求的示例中，有一段時間沒有人accept連接，而在第二個示例中，您需要更多數量的同時請求才能發生這種情況。
uj5u.com熱心網友回復：
我從很多搜索中發現，所以我想我找到了答案，但如果我有任何錯誤，我想糾正何塞先生：
1-當我們運行gen_tcp:listenERTS 時，會打開一個 ERLANG 埠（偵聽套接字）以與鏈接的 C 驅動程式進行通信，該驅動程式在主作業系統執行緒下運行會打開一個 REAL SOCKET。
2-當我們運行gen_tcp:acceptERTS 時，使用此埠使用指定的宏作為函式的引數來呼叫驅動程式 erlang:port_control，驅動程式 MAIN OS-Thread 將產生一個 OS-Thread，它將在打開的 Socket(Blocking Accept) 上運行一個真正的接受) 但這只是我的看法，我也不熟悉 CAccept函式，無論如何這是愛立信團隊的作業。
3-當客戶端發送一個連接到這個Socket的請求時，OS-Thread接受這個連接并創建一個新的與這個客戶端通信的Socket，Erlang行程創建一個新的Port并鏈接到這個OS-Thread作為與該客戶端進行此指定通信的驅動程式。
4-當Erlang行程通過這個新埠發送資料時，新驅動程式通過新的Socket發送這個資料，與接收資料相同。
5-MAIN OS-Thread 驅動程式不會在每個 Erlang 產生一個新的 OS-ThreadAccept并將在 OS-Threads 和連接之間做一個平衡（這也是 Ericsson 設計），這些執行緒將管理與已知功能之一的連接(select, poll, epoll,.....) 并且通常它epoll適用于 Linux 和KqueueBsd 系統，每個 OS-Thread 將在兩側運行此功能：一側與客戶端套接字互動，一側與 Erlang 埠互動.
這是任何驅動程式的確切作業，它隱藏了一些東西，讓模擬器的行為就像它直接完成作業一樣。
第一個問題的答案是第二個代碼更有效，就像你告訴我的那樣，當有很多 Erlang 接受器時，驅動程式知道這一點并產生許多作業系統接受器，這里還有另一個問題：我有多少接受器可以為套接字生成嗎？
自由接受器設計用于接受并行連接，很明顯，一個作業系統執行緒不能同時接受兩個連接，因此如果接受器的數量大于核心數量，例如我們有 8 個核心和 10 個核心接受者和 20 個客戶端同時到來，我們有 8 個并行接受的連接，接下來還有 8 個并行和接下來的 4 個，因此這與我們創建 8 個免費接受者的效率相同。（我談論的是正確版本的代碼，當我們有總是有 8 個空閑的接受者，當接受者接受一個連接時，它會產生一個行程來處理這個連接并回傳接受其他連接）
網路是在 Erlang/OTP 中設計容錯和可擴展服務器的最重要部分，我想在做任何事情之前很好地理解它，所以請 José 先生，如果我有什么錯誤，請告訴我謝謝。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/333372.html