5
Projektuję pętlę zdarzeń dla asynchronicznego gniazda IO przy użyciu epoll/devpoll/kqueue/poll/select (w tym windows-select).Asynchroniczne projektowanie pętli zdarzeń i problemy
mam dwie możliwości wykonywania operacji, IO:
trybnon-blocking, badanie na EAGAIN
- zestaw gniazdo w trybie non-blocking.
- Odczyt/zapis do gniazda.
- Jeśli operacja powiedzie się, po zakończeniu powiadomienia do pętli zdarzeń.
- Jeśli otrzymam EAGAIN, dodaj gniazdo do "wybierz listę" i gniazdo ankiety.
Tryb Polling: ankieta, a następnie wykonać
- gniazdo Dodaj do listy wybrać i sondować go.
- czekają na powiadomienie, że jest czytelny zapisu
- odczytu/zapisu
- postu powiadomienie o zakończeniu do pętli zdarzeń sucseeds
Dla mnie to wygląda jak pierwszy wymagałoby mniej wywołań systemowych podczas korzystania w trybie normalnym , specjalnie do pisania do gniazda (bufory są dość duże). Wygląda również na to, że można zmniejszyć narzut na liczbę "wybierz" egzekucji, szczególnie dobrze jest, gdy nie masz czegoś, co dobrze skaluje jako epoll/devpoll/kqueue.
Pytania:
- czy są jakieś zalety drugim podejściu?
- Czy występują problemy z przenośnością w przypadku nieblokujących operacji na gniazdach/deskryptorach plików w wielu systemach operacyjnych: Linux, FreeBSD, Solaris, MacOSX, Windows.
Uwagi: Proszę nie sugerować przy użyciu istniejących wdrożeń zdarzenie pętli/Gniazdo api
Nie widzę powodu, dla którego nie można czekać na przydzielenie pamięci konieczne było zastosowanie pierwszego podejścia. Czy czegoś brakuje? – Ioan
Przypuszczam, że tak, ale w praktyce nie jest to realizowane w ten sposób. W pierwszym przypadku potrzebujesz bufora dostępnego w krokach 2-4, w drugim potrzebujesz go tylko w kroku 3. – karunski