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. 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
