On Tue, May 22, 2018 at 3:01 PM Birlea Costin <[email protected]> wrote:
> Buna Ziua. > > 1.M-am uitat in laborator si in libaio.h [1] la structura io_event ca sa > vad ce campuri de date mi-ar putea oferi cati bytes au fost citit, insa > nu-mi dau seama care ar putea fi. > Am printat din campul obj (care in situatia aceasta este iocb) tot ce se > afla la iocb.u.c (adica structura io_iocb_common) si am observat ca acestea > au ramas la fel cu valorile setate cand am folosit io_prep_pread (desi > printarea a fost facuta dupa ce s-a finalizat apelul io_getevents). > Din ce spui tu, dacă field-urile sunt aceleași înseamnă că s-a citit fix cât ai spus tu să se citească, adică nbytes. Ai încercat să afișezi să vezi dacă și datele sunt în regulă? > > 2. Daca am inteles bine, asta inseamna ca in combinatie cu folosire > epoll_wait, ne anunta cand operatia a luat sfarsit deci atunci read-ul este > asigurat sa nu se blocheze, deci este deajuns doar sa verificam daca a avut > loc o eroare, altfel orice ar fi inseamna ca s-a terminat, nu? > Exact. https://code.woboq.org/linux/include/libaio.h.html#99 > > 2018-05-22 14:08 GMT+03:00 Razvan Crainea <[email protected]>: > >> Salut, Costin! >> >> Găsești răspunsurile mele inline. >> >> Numai bine, >> Răzvan >> >> On Tue, May 22, 2018 at 1:41 PM Birlea Costin <[email protected]> >> wrote: >> >>> Buna Ziua. >>> >>> Am incercat acuma sa folosesc io_set_eventfd inaintea fiecarui io_submit >>> (impreuna cu io_prep_pread) si acuma a inceput sa citeasca mai departe, >>> insa mai am 2 nelamuriri: >>> >>> 1. De unde stiu cat s-a citit la fiecare submit? observ ca io_getevents >>> doar ofera informatii despre cate evenimente s-au terminat si la fel si >>> read-ul folosit pentru asteptare. >>> >> io_getevents() returnează câte evenimente s-au terminat, în același timp >> populează field-ul events cu informații despre job-urile terminate. >> >> >>> >>> 2. Nu-mi este clar dc secventa aceasta de cod(din laboratorul 11) este >>> folosita pentru asteptarea terminarii operatiei. >>> >>> u_int64_t efd_val;if (read(efd, &efd_val, sizeof(efd_val)) < 0) { >>> /* handle error */} >>> printf >>> <http://www.opengroup.org/onlinepubs/009695399/functions/printf.html>("%llu >>> operations have completed\n", efd_val); >>> >>> >>> efd este un file descriptor al unui eveniment; un apel read() pe acest >> file descriptor va întoarce numărul de operații IO terminate. Din moment ce >> el nu este marcat ca non-blocant, read-ul pe acest file descriptor se va >> bloca până una (sau mai multe) operații vor fi terminate. Dacă mai ai >> nelămuriri, te rog să ne spui. >> >> Numai bine, >> Răzvan >> >>> >>> >>> 2018-05-22 6:55 GMT+03:00 Razvan Crainea <[email protected]>: >>> >>>> Salut, Costin! >>>> >>>> După ce se termină prim-ul job de read, citești de pe event, apoi >>>> aștepți terminarea job-ului? >>>> Ai încercat să setezi un event nou după fiecare operație? >>>> >>>> Numai bine, >>>> Răzvan >>>> >>>> On Tue, May 22, 2018 at 5:15 AM Birlea Costin via so < >>>> [email protected]> wrote: >>>> >>>>> Buna Seara. >>>>> >>>>> Nu-mi este clar cum ar trebuii schimbat offset-ul de unde citesc din >>>>> fisier atunci cand folosesc io_submit si io_prep_pread. Problema mea este >>>>> ca la fiecare submit se citeste aceeasi parte din fisier si banuiesc ca de >>>>> la offset vine problema. >>>>> >>>>> Am incercat sa reapelez io_prep_pread (fiindca aici se specifica >>>>> offset-ul) insa cand faceam asta, dupa aceea nu mai primeam deloc >>>>> event-uri >>>>> EPOLLIN pentru acest eventfd. >>>>> >>>>> Precizez ca am cate un eventfd si io_context pentru fiecare conexiune. >>>>> >>>>> Multumesc anticipat! >>>>> _______________________________________________ >>>>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii >>>> >>>> >>> >
_______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
