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

[Theodor Stoican]

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 <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/20170522/04033672/attachment-0001.html>