2017-05-22 16:04 GMT+03:00 Theodor Stoican <[email protected]>: > Ok, am inteles. Si, practic, ce ziceai tu (mai jos), trebuie implementat la > nivelul fiecarei conexiuni: > >> Poți să: >> * activezi EPOLLIN pe eventfd pentru a aștepta finalizarea citirii >> asincrone a unei bucăți din fișier >> * planifici citirea asincronă a unei bucăți din fișier >> * activezi EPOLLOUT pe socket >> * când ești notificată de epoll că poți să trimiți pe socket, trimiți >> bucata de fișier >> * dacă nu s-a trimis întreaga bucată mai aștepți un nou eveniment de >> EPOLLOUT pe socket din partea epoll și apoi trimiți ce ți-a mai rămas >> și tot așa >> * când ai terminat de trimis acea bucată, dezactivezi EPOLLOUT pe >> socket (căci deocamdată nu mai ai ce trimite) >> * o iei de la capât pentru a citi următoarea bucată din fișier > >> * când ai trimis întreg fișierul se poate închide conexiunea > > Dar daca faci asta, nu inseamna ca ramai blocat pe o anumita conexiune? > Practic, celelalte conexiuni vor stagna in felul asta pana se trimite tot > fisierul.
Nu se va bloca pe o anumită conexiune, toată treaba se face prin epoll. În obiectul epoll vei avea: * socket-ul serverului pentru listen (pentru a accepta conexiuni noi) * eventfd-uri pentru fiecare conexiune (pentru notificare terminare citire asincronă) * sockeții non-blocanți pentru fiecare conexiune (pentru trimitere fișiere) Când epoll_wait() te notifică pe un eventfd sau pe un socket, tu vei lua o acțiune ce nu este blocantă: * ori vei planifica o citire asincronă a unui chunk din fișier * ori vei fi notificat că citirea s-a terminat * ori vei trimite pe un socket non-blocant chunk-ul respectiv Astfel, se pot intercala operații pe mai multe conexiuni și niciuna nu va aștepta după alta. > Pe 22 mai 2017, 14:57, Adrian Stanciu <[email protected]> a > scris: >> >> 2017-05-22 14:36 GMT+03:00 Theodor Stoican <[email protected]>: >> > Salut, >> > >> > Merci pentru explicatii. Totusi, mai este ceva ce nu inteleg: >> > >> > In cazul in care citirile asincrone sunt integrate cu eventfd, pentru a >> > primi notificare de la kernel ca o citire s-a incheiat (in main, cand >> > apelam >> > epoll), de ce mai avem nevoie de un eventfd per conexiune (cum este >> > precizat >> > in enunt)? >> > >> >> Fiecare conexiune va avea operațiile sale de citire independent de >> celelalte conexiuni. Din această cauză vei avea un eventfd per >> conexiune, care te va notifica atunci când o operație de citire >> asincronă s-a încheiat pentru conexiunea respectivă. Asta este trecută >> în enunț ca recomandare. >> >> Dacă ai avea un singur eventfd (global, pentru toate conexiunile) >> atunci ar fi mai dificil de implementat pentru că: >> * ar trebui să ai un mecanism suplimentar de găsire a conexiunii >> pentru care a fost generat evenimentul >> * ar trebui să tratezi evenimentele agregate (o singură citire de pe >> eventfd să-ți raporteze mai multe evenimente generate). >> >> > Pe 22 mai 2017, 12:53, Adrian Stanciu <[email protected]> a >> > scris: >> >> >> >> 2017-05-22 12:32 GMT+03:00 Theodor Stoican via so >> >> <[email protected]>: >> >> > Scuze, am trimis inainte de a finisa mail-ul, din greseala. >> >> > >> >> > Revin: >> >> > Cum ar trebui sa abordam citirea dintr-un fisier asincron, respectiv >> >> > scrierea pe socket (tot asincron)? Mai specific, cand ar trebui sa >> >> > apelam >> >> > io_getevents astfel incat sa nu devina totul blocant? >> >> > >> >> > Spre exemplu, in acest sample[1], se asteapta cu io_get_events pana >> >> > se >> >> > termina toate operatiile de write, respectiv de read, daca am inteles >> >> > eu >> >> > bine. De asemenea, nu inteleg cum ar trebui sa abordam problema asta, >> >> > avand >> >> > un eventfd pentru fiecare conexiune. Nu ar trebui sa legam totul cu >> >> > io_submit la un eventfd global, folosit si de epoll? >> >> > >> >> > [1] http://www.xmailserver.org/eventfd-aio-test.c >> >> > >> >> >> >> Salut, Theodor, >> >> >> >> Ai urmărit discuția asta [1]? Sunt oferite acolo niște hint-uri. >> >> >> >> [1] http://cursuri.cs.pub.ro/pipermail/so/2015-May/016884.html >> >> >> >> Adrian _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
