[pso] Comportament ReadFile si WriteFile pe windows
Andrei Hagiescu
pso@cursuri.cs.pub.ro
Sat, 17 Apr 2004 12:44:25 +0300
This is a multi-part message in MIME format.
------=_NextPart_000_010F_01C42479.B6FBBB10
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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.=20
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?
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=20
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 =
implementez neblocant, FLUSH va fi exceptional blocanta (neomogen :( ). =
Pe de alta parte, CloseFile trebuie sa faca FLUSH sau nu ii pasa? (daca =
da, va fi si el blocant)
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?
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=20
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?
------=_NextPart_000_010F_01C42479.B6FBBB10
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Am niste nelamuriri in legatura cu ce =
se asteapta=20
exact de la comportamentul ReadFile si WriteFile deoarece exista mai =
multe=20
modele ce ar putea fi urmate, iar enuntul este foarte sumar (se spune =
doar ca=20
trebuie implementate rutinele standard read si write). Care=20
standard?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- modelul linux in care operatiile, =
atat read cat=20
si write, nu sunt blocante, read intoarce cat este in buffer, write pune =
datele=20
in buffer si iese?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>- modelul windows standard, in care =
operatia de=20
readfile este blocanta si se intoarce doar cand se completeaza numarul =
de octeti=20
trimisi sau apare time-out (la noi nu se implementeaza time-out); =
operatia de=20
write este si ea blocanta in windows, time-out posibil aparand=20
la flow-control si iarasi nu este cazul</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>- modelul windows overlapped in care =
operatiile nu=20
mai sunt blocante dar nici nu se intorc date imediat, ci la un event=20
overlapped</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Din precizari se subintelege un =
comportament ca cel=20
de pe linux sau overlapped dar nu stiu daca este imperativ si care sunt=20
specificatiile exacte de comportament. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In continuare, mai sunt cateva lucruri =
neclare la=20
precizari:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><EM><FONT face=3DArial><FONT face=3D"Times New Roman">pentru write, =
cel mai=20
simplu e sa tineti minte intr-o lista IRP-urile si sa le serviti atunci =
cand va=20
indica intreruperea; cum nu aveti voie sa faceti=20
</FONT><TT>IoCompleteRequest()</TT></FONT><FONT face=3D"Times New =
Roman"> dintr-o=20
ISR va trebui sa folositi DPC-uri</FONT></EM></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>trebuie sa tinem noi o lista? IRP-urile =
nu sunt=20
oricum tinute intern de sistemul de operare intr-o coada (serializate) =
si cand=20
se termina unul de procesat se apeleaza IoStartNextPacket?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV><FONT face=3DArial =
size=3D2>
<DIV><EM>la FLUSH o sa trebuiasca sa faceti o sincronizare cu IRP-urile =
de=20
write; cel mai simplu ar fi sa folosti o functie de completion pe =
ultimul IRP=20
din lista; nu uitati sa asteptati ca FIFO-ul sa se goleasca =
</EM></DIV></FONT>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>daca implementez blocant, FLUSH nu are =
sens (de=20
fapt are daca il apelez din alt thread, atunci ii creez un IRP si astept =
sa il=20
procesez); daca implementez neblocant, FLUSH va fi exceptional blocanta=20
(neomogen :( ). Pe de alta parte, CloseFile trebuie sa faca FLUSH sau nu =
ii=20
pasa? (daca da, va fi si el blocant)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><EM>la CLEAR nu uitati sa va sincronizati cu intreruperile si =
rutina de=20
read; cel mai simplu ar fi sa dezvactivati intreruperea de FIFO empty si =
respectiv sa folositi un mutex</EM></DIV>
<DIV><EM></EM> </DIV>
<DIV>intreruperea de FIFO empty nu se refera la terminarea transmisiei? =
ce=20
treaba are transmisia care este independenta de receptie cu golirea =
buffer-ului=20
de receptie? poate este vorba despre FIFO full ca sa nu se primeasca =
ceva in=20
timp ce se face clear?</DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>si legat tot de acest aspect in enunt=20
scrie:</FONT></DIV>
<DIV><EM>pentru a arunca eventualele date existente in bufferul intern =
al=20
driverului; dupa completarea acestei operatii, o operatie de read va =
gasi=20
bufferul gol </EM></DIV>
<DIV>daca se apeleaza CLEAR in timp ce primeam date, opresc primirea, =
curatz,=20
intorc success si pana se apeleaza read bufferul nu mai este gol. testul =
se face=20
in absenta receptiei de date de la portul serial?</DIV></BODY></HTML>
------=_NextPart_000_010F_01C42479.B6FBBB10--