[so] [Tema2][Windows] Parametru CreatePipe

Darius-Florentin Neatu neatudarius at gmail.com
Sun Apr 2 16:48:33 EEST 2017


"Deci ordinea ar fi:
1. CreateProcess(a)
2. CloseHandle(hWrite)
3. WaitProcess(a)"
Deja fac asta. O sa verific in implementare din nou (desi am verificat de
mai multe ori)

"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."
Din pacate nu am folosit la inceput acel script si mi-a facut eu un repo
manual. Nu mi-a mers din cateva incercari autentificarea din script, asa ca
am renuntat. O sa adaug manual responsabilii pentru tema.
Ti-am dat drepturi de *reporter* acum. Nu vazusem ca pentru *guest* nu poti
accesa codul. Imi poti confirma daca ai access? Daca nu, ce level ar trebui
sa iti acord?

Darius

On Sun, Apr 2, 2017 at 4:29 PM Costin Lupu <costin.lup at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20170402/5095bb45/attachment.html>


More information about the so mailing list