[so] [Tema5][Linux][Operatii asincrone]

[Adrian Stanciu]

2017-05-22 16:04 GMT+03:00 Theodor Stoican <theo.stoican at gmail.com>:
> 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 <adrian.stanciu.pub at gmail.com> a
> scris:
>>
>> 2017-05-22 14:36 GMT+03:00 Theodor Stoican <theo.stoican at gmail.com>:
>> > 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 <adrian.stanciu.pub at gmail.com> a
>> > scris:
>> >>
>> >> 2017-05-22 12:32 GMT+03:00 Theodor Stoican via so
>> >> <so at cursuri.cs.pub.ro>:
>> >> > 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