[so] [SO][Tema2][General | Windows] Probleme?

Tue Apr 2 07:35:18 EEST 2019

Cred că 0 nu, dar citirile pot returna câte 1 singur octet fiecare teoretic.

On Tue, Apr 2, 2019, 07:34 Ionuț Mihalache <ipopescu46 at gmail.com> wrote:

> Adică la un moment dat se pot citi 0 octeți fără să se fi ajuns la finalul
> pipe-ului, corect?
>
> mar., 2 apr. 2019, 02:12 Adrian Șendroiu <molecula2788 at gmail.com> a scris:
>
>> Pare bine partea de lansat procese și redirectarea din pipe.
>>
>> Acum, dacă mă uit mai atent, problema la tine pare să fie în logica de
>> fread. Nu prea înțeleg foarte bine algoritmul, dar se pare că
>> presupunerea ta este că ReadFile o să întoarcă mereu 4096 de bytes, cu
>> excepția ultimului bloc care poate fi mai mic.
>>
>> Ori în cazul pipe-ului nu mai e adevărat asta. ReadFile poate întoarce
>> orice număr de bytes, depinde câți au fost în pipe la momentul
>> respectiv.
>>
>> În ultima variantă de checker am scos sleep-ul și verificarea
>> numărului de syscalluri pentru testul ăsta. Ar trebui să meargă și
>> așa.
>>
>> On Tue, 2 Apr 2019 at 00:46, Ionuț Mihalache <ipopescu46 at gmail.com>
>> wrote:
>> >
>> > Bun, atunci cred că am găsit problema să zic. Eu închideam capul de
>> scriere respectiv de citire în părinte imediat ce cream procesul copil. Cel
>> mai probabil prin schimbarea de context câteodată părintele ajungea să
>> închidă acel cap de scriere respectiv de citire și atunci pipe-ul devenea
>> inutilizabil. Însă revin la indicațiile pe care mi le-a dat Adrian. Dacă nu
>> las sleep nu merge orice aș face. Bănuiesc că sleep trebuie să fie pentru
>> ca testul să funcționeze corect, nu?
>> >
>> > În mar., 2 apr. 2019 la 00:32, Paul Olaru <olarupaulstelian97 at gmail.com>
>> a scris:
>> >>
>> >> Sistemul de operare nu trebuie să raporteze EOF la capătul de citire
>> atâta timp cât există un capăt de scriere deschis. Că e Windows, că e Linux.
>> >>
>> >> On Tue, Apr 2, 2019, 00:30 Ionuț Mihalache <ipopescu46 at gmail.com>
>> wrote:
>> >>>
>> >>> Păi dacă procesul copil nu apucă să scrie cu type pe pipe procesul
>> părinte nu-l vede ca fiind gol chiar dacă procesul copil mai are de scris
>> și a fost scos de pe procesor? Încă nu exclud posibilitatea ca eu să am un
>> bug în cod însă am comentat toate liniile unde verific dacă s-a ajuns la
>> EOF, practic testul ar trebui să cicleze însă tot primesc aceeași eroare.
>> Eu chiar nu cred că este ceva din codul meu pentru că sunt câteva linii și
>> nu au o logică dubioasă. Dacă las acel sleep merge pentru așa cum este și
>> în comentariu în test este nevoie de el pentru ca procesul copil să poate
>> scrie datele pe pipe. Nu există șansa ca eu să fi avut ghinion și pur și
>> simplu să fi trimis tema fix când vmchecker a început să fie problematic.
>> Eu sunt destul de sigur că problema este de la preemptare nu de la mine.
>> >>>
>> >>> În lun., 1 apr. 2019 la 23:30, Adrian Șendroiu <
>> molecula2788 at gmail.com> a scris:
>> >>>>
>> >>>> Da, ideea este că la tine se ajunge în pclose prea repede și se
>> >>>> închide pipe-ul în timp ce type încă încearcă să mai scrie în el, de
>> >>>> unde și eroarea cu "The process tried to write to a nonexistent
>> pipe".
>> >>>>
>> >>>> N-ar trebui să se întâmple asta pentru că testul face
>> >>>> while(!so_feof(f)) și apoi pclose. Deci înseamnă că cumva so_feof
>> >>>> raportează EOF mai devreme decât trebuie.
>> >>>>
>> >>>> On Mon, 1 Apr 2019 at 22:52, Ionuț Mihalache <ipopescu46 at gmail.com>
>> wrote:
>> >>>> >
>> >>>> > Din ce am citit aici [1] problema ar fi de la modul cum
>> functioneaza type.
>> >>>> >
>> >>>> > Am incercat sa ma uit pe cod sa vad daca exista vreun bug ciudat
>> si chiar nu vad ce ar putea fi. Problema mea este ca 'The process tried to
>> write to a nonexistent pipe.' insa testul face fread. Singura scriere este
>> generata de comanda type din test si de asta zic eu ca ar crapa programul
>> cateodata nefiind neaparat problema la codul scris de mine, dar ma mai uit
>> insa chiar nu mai stiu la ce ca sa identific problema.
>> >>>> >
>> >>>> > [1] -
>> https://stackoverflow.com/questions/40066965/my-c-sharp-program-gives-an-error-the-process-tried-to-write-to-a-nonexistent-p?rq=1
>> >>>> >
>> >>>> > În lun., 1 apr. 2019 la 19:58, Adrian Șendroiu <
>> molecula2788 at gmail.com> a scris:
>> >>>> >>
>> >>>> >> Nu, e suficient. Dar vezi să nu ai alt bug sau ceva, pentru că
>> dacă
>> >>>> >> rulezi cum zic eu îți crapă programul.
>> >>>> >>
>> >>>> >> On Mon, 1 Apr 2019 at 18:59, Ionuț Mihalache <
>> ipopescu46 at gmail.com> wrote:
>> >>>> >> >
>> >>>> >> > Pentru a verifica dacă s-a ajuns la eof verific în fread dacă
>> ReadFile a întors FALSE și apoi getlasterror și ies dacă este acea eroare
>> din enunț, ar trebui să mai fac ceva?
>> >>>> >> >
>> >>>> >> > lun., 1 apr. 2019, 18:52 Adrian Șendroiu <
>> molecula2788 at gmail.com> a scris:
>> >>>> >> >>
>> >>>> >> >> Salut,
>> >>>> >> >>
>> >>>> >> >> Cred că ai o problemă cu semnalizarea EOF-ului.
>> >>>> >> >>
>> >>>> >> >> Încearcă următoarea chestie: în test_popen_read.c comentează
>> acel
>> >>>> >> >> "Sleep(2000)", precum și linia "FAIL_IF(num_ReadFile !=
>> >>>> >> >> expected_sys_read...".
>> >>>> >> >>
>> >>>> >> >> În cazul ăsta o să-ți dea eroarea respectivă la fiecare rulare.
>> >>>> >> >>
>> >>>> >> >> On Sun, 31 Mar 2019 at 09:11, Paul Olaru <
>> olarupaulstelian97 at gmail.com> wrote:
>> >>>> >> >> >
>> >>>> >> >> > La testul 32, pot fi chestii de scheduler. Cred că ar fi
>> importantă de fapt ordinea (la "r" aștepți și după închizi, la "w" închizi
>> și după aștepți). Nici eu nu am implementat asta tbh. Dar și la "aștepți și
>> după închizi" sunt neajunsuri.
>> >>>> >> >> >
>> >>>> >> >> > Sunt surprins că pe Linux reușește checkerul să preia el
>> toate datele înainte de a apela pclose.
>> >>>> >> >> >
>> >>>> >> >> > On Sun, Mar 31, 2019, 02:05 Ionuț Mihalache via so <
>> so at cursuri.cs.pub.ro> wrote:
>> >>>> >> >> >>
>> >>>> >> >> >> Și acum a mers. Arhiva este aceeași.
>> >>>> >> >> >>
>> >>>> >> >> >> În dum., 31 mar. 2019 la 02:02, Ionuț Mihalache <
>> ipopescu46 at gmail.com> a scris:
>> >>>> >> >> >>>
>> >>>> >> >> >>> Salut,
>> >>>> >> >> >>>
>> >>>> >> >> >>> Iar mi-a apărut eroarea asta „The process tried to write
>> to a nonexistent” pipe. la testul 32. O să trimit iarăși însă mi se pare
>> ciudat pentru că am rulat pe mașina virtuală de 10 ori la rând și nu am
>> avut eroarea asta.
>> >>>> >> >> >>>
>> >>>> >> >> >>> În sâm., 30 mar. 2019 la 19:04, Adrian Șendroiu <
>> molecula2788 at gmail.com> a scris:
>> >>>> >> >> >>>>
>> >>>> >> >> >>>> Salut,
>> >>>> >> >> >>>>
>> >>>> >> >> >>>> M-am uitat și pare ok. O fi fost de la vmchecker.
>> >>>> >> >> >>>>
>> >>>> >> >> >>>> On Sat, 30 Mar 2019 at 18:15, Ionuț Mihalache via so
>> >>>> >> >> >>>> <so at cursuri.cs.pub.ro> wrote:
>> >>>> >> >> >>>> >
>> >>>> >> >> >>>> > Salut,
>> >>>> >> >> >>>> >
>> >>>> >> >> >>>> > Am trimis pentru prima dată tema2 pe windows și părea
>> că a intrat în buclă infinită la testul 20. După ce am mai trimis încă o
>> dată la penultimul test am primit eroare cu non-existing pipe. După am mai
>> trimis încă de 3 ori și de fiecare dată am primit 95/95. Este posibil să
>> fie ceva de la vmchecker sau să mă mai uit pe cod să văd dacă am niște
>> bug-uri care apar mai rar?
>> >>>> >> >> >>>> > _______________________________________________
>> >>>> >> >> >>>> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii
>> >>>> >> >> >>
>> >>>> >> >> >> _______________________________________________
>> >>>> >> >> >> 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/20190402/c1b8a380/attachment.html>