[so] [Tema 5][Linux][Offset io_prep_pread]

[Birlea Costin]

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

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?


https://code.woboq.org/linux/include/libaio.h.html#99

2018-05-22 14:08 GMT+03:00 Razvan Crainea <razvan.crainea at gmail.com>:

> Salut, Costin!
>
> Găsești răspunsurile mele inline.
>
> Numai bine,
> Răzvan
>
> On Tue, May 22, 2018 at 1:41 PM Birlea Costin <costin.birlea at gmail.com>
> 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 <razvan.crainea at gmail.com>:
>>
>>> 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 <
>>> so at cursuri.cs.pub.ro> 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
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20180522/5e3a7fba/attachment-0001.html>