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

Theodor Stoican theo.stoican at gmail.com
Tue May 23 14:29:08 EEST 2017


Multumesc Adrian, pentru explicatii.

Pe 22 mai 2017, 17:31, Adrian Stanciu <adrian.stanciu.pub at gmail.com> a
scris:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20170523/fad92029/attachment.html>


More information about the so mailing list