[so] [Tema2][Windows] Parametru CreatePipe

[Costin Lupu]

On 04/02/2017 03:44 PM, Darius-Florentin Neatu wrote:
> Eu intrebasem despre limita pentru nSize de la Pipe pentru ca in
> implementarea de pe Windows fac a | b | c serial. Adica dupa ce s-a
> terminat a, b incepe sa citeasca. Dupa ce s-a terminat b, c incepe sa
> citeasca.

Aici e o problemă. Subcomenzile a, b și c *trebuie* să ruleze în 
paralel. De altfel ne putem gândi la operatorul '|' ca la un operator de 
paralelizare, cu diferența că subcomenzile comunică între ele.

> Cu limita cel putin 20000000 pentru nSize trec toate testele local &
> vmchecker (doar 2 teste au nevoie de limita > cea default), dar as vrea
> imi iasa pipe-ul eficient si pe windows.

Ce te faci dacă între a, b și c se transferă mai mult de 20MB? Ai avut 
noroc că nu e cazul în suita de teste.

> Am o varianta in care fac paralel. Ex: a | b (b sa poate citi din pipe
> imediat dupa ce a face primul write).

Asta e varianta pe care trebuie s-o implementezi.

> In do_on_pipe fac 2 threaduri:
> - thread 1: redirect, CreateProcess("a", ..), undo redirect (inchide
> handle de fisiere deschisi in redirect sau veniti de la comanda parinte
> pentru pipe  - deci inchide write handle din pipe)
> - thread 2: redirect, CreateProcess("b", ...)  si nu se opreste

E clar aici că procesul b așteaptă să citească ceva pentru că celălalt 
capăt (cel de scriere) nu a fost închis.

> Cand rulez a | b apare in terminal tot rezultatul comenzii "a | b", am
> pus printuri in program: thread 1 asteapta procesul copil corespunzator
> lui a, face close la capatul de write, da ExitThread(cod_copil), iar
> parintele il asteapta cu success.

Ideea e să închizi în părinte capătul de scriere de îndată ce nu mai 
nevoie de el, adică după CreateProcess și înainte de terminarea 
procesului a. Deci ordinea ar fi:
1. CreateProcess(a)
2. CloseHandle(hWrite)
3. WaitProcess(a)

> Cu toate acestea comanda b ramane in asteptare. Eu ma asteptam ca
> aceasta abordare sa fie corecta: procesul b sa se opreasca deoarece s-a
> terminat procesul a si in thread1 am inchis capatul de write. Deci cand
> el termina de citit tot din pipe.
>
> As vrea sa stiu daca logica mea e buna. Am tot modificat configurarile,
> in niciuna nu se opreste b.

Logica pare ok. Din păcate nu pot să mă uit pe codul tău pentru că n-am 
access la fișiere. Folosește uneltele de care ți-a zis și Mihai pentru a 
vedea ce handle-uri rămân agățate.

> Implementarea se gaseste pe Gitlab[1]. Diferenta intre cele 2 abordari
> de la pipe o face linia 552.
> // #define PIPE_WITH_THREADS
> Afecteaza doar comportamentul functiei do_on_pipe.
>
> P.S. Am dat access pentru Costin si Razvan. Unde gasesc lista cu
> resposabilii de la tema X? (sa le pot da access tuturor pentru etapa de
> corectare)

Am acces la proiect, dar n-am acces la fișiere. Vezi că e scriptul de 
care ți-a zis și Mihai mai devreme și care dă acces la toată echipa de teme.

Costin