Saya baru-baru ini melihat skenario yang diuji di mana beberapa utas disurvei pada soket unix-domain yang mendengarkan dan kemudian menerima koneksi. Semua utas dibangunkan menggunakan panggilan sistem poll().
Ini adalah build kustom dari kernel linux daripada build distro, jadi mungkin ada opsi konfigurasi kernel yang mengubahnya, tetapi saya tidak tahu akan seperti apa.
Kami tidak mencoba epoll.
Selama bertahun-tahun, sebagian besar kernel unix/linux membuat serial tanggapan terhadap accept(2), dengan kata lain, hanya satu utas yang dibangunkan jika lebih dari satu utas memblokir pada accept(2) terhadap satu deskriptor file terbuka.
OTOH, banyak (jika tidak semua) kernel masih memiliki masalah kumpulan yang menggelegar dalam pola pilih-terima seperti yang Anda jelaskan.
Saya telah menulis skrip sederhana ( https://Gist.github.com/kazuho/10436253 ) untuk memverifikasi keberadaan masalah, dan menemukan bahwa masalahnya ada di linux 2.6.32 dan Darwin 12.5.0 (OS X 10.8 .5).
Ini adalah masalah yang sangat lama, dan sebagian besar tidak ada lagi. Kernel Linux (selama beberapa tahun terakhir) telah mengalami sejumlah perubahan dengan caranya menangani dan merutekan paket ke tumpukan jaringan, dan menyertakan banyak pengoptimalan untuk memastikan latensi rendah, dan keadilan (yaitu, meminimalkan kelaparan).
Artinya, pilih sistem memiliki sejumlah masalah skalabilitas hanya melalui API-nya. Ketika Anda memiliki deskriptor file dalam jumlah besar, biaya panggilan pilih sangat tinggi. Ini terutama karena harus membuat, memeriksa, dan memelihara set FD yang diteruskan ke dan dari panggilan sistem.
Saat ini, cara yang lebih disukai untuk melakukan IO asinkron adalah dengan epoll . API jauh lebih sederhana dan dapat diskalakan dengan sangat baik di berbagai jenis beban (banyak koneksi, banyak throughput, dll.)