[so] [Tema1][Windows] Pipe-uri

[Drutu Bogdan]

2011/5/25 Cosmin Stefan-Dobrin <cosminstefanxp at gmail.com>:
> Revin si cu un "screen" al ce se intampla, pentru a reliefa mai bine (in
> paranteza dupa debug e threadID si la handle-uri sunt handle-urile (primul
> hRead, al doilea hWrite):
>
>> echo "test" | cat | nl
> [DEBUG][3484] Command successfully read: echo "test" | cat | nl
>
> [DEBUG][3484] Parallel command detected
> [DEBUG][3484] Piped Command detected.
> [DEBUG][3484] Created pipe with handle (2016,1996)
> [DEBUG][3484]   Created threads 3488 - 3492
> [DEBUG][3488] Thread started with command tree: 00322B20
> [DEBUG][3488] Parallel command detected
> [DEBUG][3488] Piped Command detected.
> [DEBUG][3488] Created pipe with handle (1984,1976)
> [DEBUG][3488]   Created threads 3496 - 3500
> [DEBUG][3492] Thread started with command tree: 00322B90
> [DEBUG][3492] Simple command detected...
> [DEBUG][3492] Verb:
>                 nl
> [DEBUG][3492] Full parameters list: nl
> [DEBUG][3492] Preparing redirections...
> [DEBUG][3492] ---------------------------------------------------------
> [DEBUG][3492]   Closing IN handle 2016
> [DEBUG][3496] Thread started with command tree: 00322A88
> [DEBUG][3496] Simple command detected...
> [DEBUG][3496] Verb:
>                 echo
> [DEBUG][3496] Full parameters list: echo  "test"
> [DEBUG][3496] Preparing redirections...
> [DEBUG][3496] ---------------------------------------------------------
> [DEBUG][3496]   Closing OUT handle 1976
> [DEBUG][3500] Thread started with command tree: 00322B00
> [DEBUG][3500] Simple command detected...
> [DEBUG][3500] Verb:
>                 cat
> [DEBUG][3500] Full parameters list: cat
> [DEBUG][3500] Preparing redirections...
> [DEBUG][3500] ---------------------------------------------------------
>      1  test
> [DEBUG][3500]   Closing IN handle 1984
> [DEBUG][3500]   Closing OUT handle 1996
> [DEBUG][3496] ---------------------------------------------------------
> [DEBUG][3496] Process returned 0
> [DEBUG][3488] Thread 0 finished with return value 0.
>
>
> --
> Cosmin
>
>
> 2011/5/25 Cosmin Stefan-Dobrin <cosminstefanxp at gmail.com>
>>
>> Salutare,
>>
>> Am si eu o mica problema cu pipe-urile pe Windows si nu reusesc sa-mi dau
>> seama ce are. Ei bine, ideea e ca pana acum totul ne merge bine, mai putin
>> cazul in care avem mai mult de 2 pipe-uri inlantuite. Daca avem: 'echo ana |
>> nl' totul e ok. In schimb daca avem 'echo ana | cat | nl', operatia o face
>> cu succes, dar nu se termina. Procesul lui echo se inchide, in schimb
>> celelalte 2 nu. Deci probabil ele inca mai asteapta ceva pe Pipe-uri, desi
>> eu zic ca le-am inchis cum trebuie (Altfel nu se termina nici pentru 2
>> pipe-uri).
>>
>> Ideea e ca noi am folosit threaduri. Cand dam peste o comanda paralela,
>> sunt create doua threaduri, fiecare ocupandu-se de o jumate de arbore. In
>> fiecare moment fiecare thread (inclusiv cel principal) stie ce handle-uri
>> are pentru in/out/err. Initial acestea sunt stdin/out/err, dar atunci cand
>> creez un pipe, ii comunic thrreadului ca , de exemplu, out-ul lui e
>> handle-ul cutare. Threadul, dupa ce va crea procesul ce executa comanda,
>> daca stie ca un cap e pipe, il inchide.
>>
>> Din codul de debug pe care il am se vede ca pe procesul parinte (cu
>> threaduri cu tot) se inchid toate cele 4 capete ale celor 2 pipe-uri create
>> (in cazul exemplului de mai sus), dar tot nu se inchid procesele spawn-uite.
>>
>> Conteaza ordinea in care sunt inchise pipe-urile (atat timp cat sunt
>> inchise de thread dupe ce creaza procesul comenzii si inainte sa il
>> astepte)?
>> Exista vreun flag necesar pentru a trimite pe pipe EOF cand se inchide
>> Handle-ul?

Trebuie sa inchizi capetele pipe-urilor si in procesul parinte, pentru
ca ele raman deschise si asta poate fi un motiv pentru care celelalte
procese cred ca mai au de unde sa primeasca date si nu se termina.
(Adica nu primesc eventul de pipe closed si raman blocate in read).

>>
>> Thanks a lot,
>> Cosmin
>>
>
>
> _______________________________________________
> http://elf.cs.pub.ro/so/wiki/resurse/lista-discutii
>



-- 
Bogdan.