[pso] Comportament ReadFile si WriteFile pe windows

[Octavian Purdila]

On Saturday 17 April 2004 12:44, Andrei Hagiescu wrote:
> Am niste nelamuriri in legatura cu ce se asteapta exact de la
> comportamentul ReadFile si WriteFile deoarece exista mai multe modele ce ar
> putea fi urmate, iar enuntul este foarte sumar (se spune doar ca trebuie
> implementate rutinele standard read si write). Care standard?
>
> - modelul linux in care operatiile, atat read cat si write, nu sunt
> blocante, read intoarce cat este in buffer, write pune datele in buffer si
> iese? 
> - modelul windows standard, in care operatia de readfile este 
> blocanta si se intoarce doar cand se completeaza numarul de octeti trimisi
> sau apare time-out (la noi nu se implementeaza time-out); operatia de write
> este si ea blocanta in windows, time-out posibil aparand la flow-control si
> iarasi nu este cazul - modelul windows overlapped in care operatiile nu mai
> sunt blocante dar nici nu se intorc date imediat, ci la un event overlapped
>
> Din precizari se subintelege un comportament ca cel de pe linux sau
> overlapped dar nu stiu daca este imperativ si care sunt specificatiile
> exacte de comportament.
>

Alegeti ce comportament doriti voi, nu se impune nimic.

> In continuare, mai sunt cateva lucruri neclare la precizari:
>
> pentru write, cel mai simplu e sa tineti minte intr-o lista IRP-urile si sa
> le serviti atunci cand va indica intreruperea; cum nu aveti voie sa faceti
> IoCompleteRequest() dintr-o ISR va trebui sa folositi DPC-uri
>
> trebuie sa tinem noi o lista? IRP-urile nu sunt oricum tinute intern de
> sistemul de operare intr-o coada (serializate) si cand se termina unul de
> procesat se apeleaza IoStartNextPacket?
>

Ba da, dar voi nu aveti acces la coada respectiva.  

> la FLUSH o sa trebuiasca sa faceti o sincronizare cu IRP-urile de write;
> cel mai simplu ar fi sa folosti o functie de completion pe ultimul IRP din
> lista; nu uitati sa asteptati ca FIFO-ul sa se goleasca
>
> daca implementez blocant, FLUSH nu are sens (de fapt are daca il apelez din
> alt thread, atunci ii creez un IRP si astept sa il procesez); daca

Deci are sens.

> implementez neblocant, FLUSH va fi exceptional blocanta (neomogen :( ). Pe

Rolul operatiei FLUSH este unul de sincronizare. Atunci cand se termina apelul 
flush, toate datele ar trebui sa fi plecat pe fir. FLUSH trebuie sa fie deci 
blocant.

> de alta parte, CloseFile trebuie sa faca FLUSH sau nu ii pasa? (daca da, va
> fi si el blocant)
>

Cum vreti.

> la CLEAR nu uitati sa va sincronizati cu intreruperile si rutina de read;
> cel mai simplu ar fi sa dezvactivati intreruperea de FIFO empty si
> respectiv sa folositi un mutex
>
> intreruperea de FIFO empty nu se refera la terminarea transmisiei? ce
> treaba are transmisia care este independenta de receptie cu golirea
> buffer-ului de receptie? poate este vorba despre FIFO full ca sa nu se
> primeasca ceva in timp ce se face clear?
>

Da, este vorba de intreruperea "Received Data Available". Am corectat si 
enuntul. 

> si legat tot de acest aspect in enunt scrie:
> pentru a arunca eventualele date existente in bufferul intern al
> driverului; dupa completarea acestei operatii, o operatie de read va gasi
> bufferul gol 

> daca se apeleaza CLEAR in timp ce primeam date, opresc 
> primirea, curatz, intorc success si pana se apeleaza read bufferul nu mai
> este gol. testul se face in absenta receptiei de date de la portul serial?

Da, se considera cu nu se primesc date in timpul operatiei CLEAR. De fapt, 
daca va uitati pe test o sa vedeti ca se face intai un FLUSH pe portul de 
transmisie si _dupa_ accea se face un CLEAR pe portul de receptie.  Asta 
inseamna ca operatia de CLEAR se va face fara receptionare de date.

tavi