[so] nelamurire privind asincr.
George Ciobanu
so@atlantis.cs.pub.ro
Sun, 7 Dec 2003 08:34:39 -0800 (PST)
--0-65181631-1070814879=:88262
Content-Type: text/plain; charset=us-ascii
Salut,
1. In cazul temei veti folosi notificarea prin semnale. Ce era in paranteze era o observatie ...
Aveti grija ca se pot pierde semnale. In acest caz eroarea (returnata de aio_error) este setata in mod corespunzator iar aio_return va returna -1.
2. Ramane la alegerea ta cum rezolvi aceasta problema. (Daca spargi in bucati ,cel mai simplu ar fi sa citesti cate o bucata si sa o scrii. ) Rezolvarea tb specificata in README
Cristian Zamfir <zamfir@fx.ro> wrote:
On Sunday 07 December 2003 17:23, George Ciobanu wrote:
Nedumeriri:
a) Sa inteleg din raspunsul la intrebarea 1 ca putem sa folosim optiunea cu
SIGEV_THREAD pentru threadurile de tip a). In cazul asta vad ca se creeaza un
thread nou si nu stiu daca mai e nevoie de semnale, cum e precizat in enuntul
temei.
'struct sigevent aio_sigevent'
This element specifies how the calling process is notified
once the operation terminates. If the `sigev_notify' element
is `SIGEV_NONE', no notification is sent. If it is
`SIGEV_SIGNAL', the signal determined by `sigev_signo' is
sent. Otherwise, `sigev_notify' must be `SIGEV_THREAD'. In
this case, a thread is created which starts executing the
function pointed to by `sigev_notify_function'.
b) In enunt nu se precizeaza daca fisierele au o lungime maxima, iar in caz ca
se poate orice lungime, care e politica care trebuie implementata?
Sa ziceam ca avem de facut aio_read, si avind in vedere ca nu se stie ordinea
in care sunt solutionate cererile AIO, este posibil ca pachetele sa ajunga in
alta ordine la client si unul dintre server si client ar trebui sa
reinventeze partea din tcp legata de reordonarea pachetelor.
Daca asteptam sa se execute aio_read pentru fiecare bucatica din fisierul
cerut, si apoi facem un aio_read pentru urmatoarea bucatica, se complica
implementarea cozii sau pipe-ului pentru comunicarea intre worker-thread-uri
si threadul principal al serverului.
Multumesc
> Toma Monica wrote:
>
> Multumesc de raspuns, insa mai sunt ceva pb care mi-au
> ramas neclare :).
>
> 1. Practic thread-urile worker vor trata cererile care
> le sunt asignate de server secvential, doar ca
> operatiile de citire/scriere se fac asincron?
>
> Dat fiind ca in server dai intr-un singur loc dai accept cererile vor fi
> secventializate oricum. Cererile nu sunt tratate secevential; ele vor fi
> pornite de folosind operatii operatii asincrone. Daca se termina mai multe
> in acelasi timp poti sa secventializezi raspunsurile ( desi pe linux, daca
> folosesti notificare folosind thread-uri ar putea raspunde chiar ele)
>
>
>
> 2. Thread-urile de tip a/b trebuie sa poata sa execute
> mai multe operatii in acelasi timp, pe mai multe
> fisiere?
>
> Da
>
> 3. Thread-urile trebuie sa fie pornite tot timpul,
> adica la lansarea server-ului sa se creeze toate
> thread-urile worker ( sugestia ne-a fost data la
> laborator) sau in momentul in care vine o cerere si
> exista un "loc liber" sa se lanseze un thread
> corespunzator operatiei, care sa se termine in
> momentul in care s-a incheiat operatia pe care o
> executa?
>
>
> Crearea lor se face la inceput. Oprirea lor se face numai atunci cand se
> opreste serverul (deci, in cazul nostru cam niciodata)
>
> --- George Ciobanu wrote:
> > Salut,
> >
> > Serverul ar trebui sa faca numai load balancing;
> > deci un thread de tip ls tb sa trimita raspunsul
> > singur la client fara participarea serverului. E ok
> > ca threadul de tip ls sa poata prelua numai o
> > operatie la un moment dat, dar tb sa te asiguri ca
> > serverul nu se blocheaza ( serverul poate trimite
> > toate cele 5 cereri, iar threadul respectiv le
> > trateaza secvential)
> > Partea de asincronism este impusa numai pentru
> > celelalte doua tipuri de threaduri. Dar, ca raspuns
> > la intrebarea ta asincronismul implica apeluri
> > neblocante.
> >
> > Toma Monica wrote:
> >
> > Buna, am si eu cateva nelamuriri, si desi risc sa
> > par
> > stupida, nu am gasit pe nimeni care sa poate sa imi
> > fie de ajutor...
> > Iata care sunt problemele mele:
> >
> > 1. sa presupunem ca avem 5 clienti care se se
> > conecteaza la server pt a cere un ls, iar serverul
> > dispune doar de un thread care face aceasta
> > operatie.
> > Eu am ales ca serverul ( thread-ul principal) sa
> > comunica cu thread-urile worker (prin care executa
> > operatiile) folosind pipe-uri. Ideea e ca citirea de
> > pe pipe am facut-o cu read(blocant) adica un thread
> > worker al serverului isi verifica pipe-ul si dc are
> > operatie o citeste de pe pipe si o executa, deci un
> > thread va putea executa la un moment dat numai o
> > operatie din cele care ii sunt asignate de server ->
> > contravine aceasta metoda cu ideea de asincron?
> > Revenind la cei 5 clienti, dupa ce se obtine
> > rezultatul listarii, acesta trebuie trimis la
> > clienti.Rezultatul este memorat pe server intr-un
> > fisier si apoi citit si trimis la client. Trebuie
> > aceasta citire sa fie si ea asincrona?
> >
> > Probabil voi astepta raspuns la aceasta intrebare
> > inainte sa mai inaintez si altele. S-ar putea sa ma
> > lamuresc.
> >
> > Se poate folosi functia sprintf?
> >
> > Da
> >
> >
> >
> > =====
> >
> > I dream of finding myself laughing!
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > New Yahoo! Photos - easier uploading and sharing.
> > http://photos.yahoo.com/
> > _______________________________________________
> > so mailing list
> > so@atlantis.cs.pub.ro
>
> http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so
>
> > ---------------------------------
> > Do you Yahoo!?
> > New Yahoo! Photos - easier uploading and sharing
>
> =====
>
> I dream of finding myself laughing!
>
>
> __________________________________
> Do you Yahoo!?
> New Yahoo! Photos - easier uploading and sharing.
> http://photos.yahoo.com/
> _______________________________________________
> so mailing list
> so@atlantis.cs.pub.ro
> http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so
>
>
>
> ---------------------------------
> Do you Yahoo!?
> New Yahoo! Photos - easier uploading and sharing
_______________________________________________
so mailing list
so@atlantis.cs.pub.ro
http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so
---------------------------------
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing
--0-65181631-1070814879=:88262
Content-Type: text/html; charset=us-ascii
<DIV>Salut, </DIV>
<DIV> </DIV>
<DIV>1. In cazul temei veti folosi notificarea prin semnale. Ce era in paranteze era o observatie ...</DIV>
<DIV><STRONG>Aveti grija ca se pot pierde semnale. In acest caz eroarea (returnata de aio_error) este setata in mod corespunzator iar aio_return va returna -1.</STRONG> </DIV>
<DIV>2. Ramane la alegerea ta cum rezolvi aceasta problema. (Daca spargi in bucati ,cel mai simplu ar fi sa citesti cate o bucata si sa o scrii. ) Rezolvarea tb specificata in README</DIV>
<DIV><BR><BR><B><I>Cristian Zamfir <zamfir@fx.ro></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">On Sunday 07 December 2003 17:23, George Ciobanu wrote:<BR><BR>Nedumeriri:<BR><BR>a) Sa inteleg din raspunsul la intrebarea 1 ca putem sa folosim optiunea cu <BR>SIGEV_THREAD pentru threadurile de tip a). In cazul asta vad ca se creeaza un <BR>thread nou si nu stiu daca mai e nevoie de semnale, cum e precizat in enuntul <BR>temei.<BR><BR><BR>'struct sigevent aio_sigevent'<BR>This element specifies how the calling process is notified<BR>once the operation terminates. If the `sigev_notify' element<BR>is `SIGEV_NONE', no notification is sent. If it is<BR>`SIGEV_SIGNAL', the signal determined by `sigev_signo' is<BR>sent. Otherwise, `sigev_notify' must be `SIGEV_THREAD'. In<BR>this case, a thread is created which starts executing the<BR>function pointed to by `sigev_notify_function'.<BR><BR>b) In enunt nu se precizeaza daca fisierele au o lungime maxima, iar in caz ca <BR>se poate orice
lungime, care e politica care trebuie implementata? <BR>Sa ziceam ca avem de facut aio_read, si avind in vedere ca nu se stie ordinea <BR>in care sunt solutionate cererile AIO, este posibil ca pachetele sa ajunga in <BR>alta ordine la client si unul dintre server si client ar trebui sa <BR>reinventeze partea din tcp legata de reordonarea pachetelor.<BR>Daca asteptam sa se execute aio_read pentru fiecare bucatica din fisierul <BR>cerut, si apoi facem un aio_read pentru urmatoarea bucatica, se complica <BR>implementarea cozii sau pipe-ului pentru comunicarea intre worker-thread-uri <BR>si threadul principal al serverului.<BR><BR>Multumesc<BR><BR><BR><BR>> Toma Monica <MONIQQUS@YAHOO.COM>wrote:<BR>><BR>> Multumesc de raspuns, insa mai sunt ceva pb care mi-au<BR>> ramas neclare :).<BR>><BR>> 1. Practic thread-urile worker vor trata cererile care<BR>> le sunt asignate de server secvential, doar ca<BR>> operatiile de citire/scriere se fac asincron?<BR>><BR>>
Dat fiind ca in server dai intr-un singur loc dai accept cererile vor fi<BR>> secventializate oricum. Cererile nu sunt tratate secevential; ele vor fi<BR>> pornite de folosind operatii operatii asincrone. Daca se termina mai multe<BR>> in acelasi timp poti sa secventializezi raspunsurile ( desi pe linux, daca<BR>> folosesti notificare folosind thread-uri ar putea raspunde chiar ele)<BR>><BR>><BR>><BR>> 2. Thread-urile de tip a/b trebuie sa poata sa execute<BR>> mai multe operatii in acelasi timp, pe mai multe<BR>> fisiere?<BR>><BR>> Da<BR>><BR>> 3. Thread-urile trebuie sa fie pornite tot timpul,<BR>> adica la lansarea server-ului sa se creeze toate<BR>> thread-urile worker ( sugestia ne-a fost data la<BR>> laborator) sau in momentul in care vine o cerere si<BR>> exista un "loc liber" sa se lanseze un thread<BR>> corespunzator operatiei, care sa se termine in<BR>> momentul in care s-a incheiat operatia pe care o<BR>>
executa?<BR>><BR>><BR>> Crearea lor se face la inceput. Oprirea lor se face numai atunci cand se<BR>> opreste serverul (deci, in cazul nostru cam niciodata)<BR>><BR>> --- George Ciobanu wrote:<BR>> > Salut,<BR>> ><BR>> > Serverul ar trebui sa faca numai load balancing;<BR>> > deci un thread de tip ls tb sa trimita raspunsul<BR>> > singur la client fara participarea serverului. E ok<BR>> > ca threadul de tip ls sa poata prelua numai o<BR>> > operatie la un moment dat, dar tb sa te asiguri ca<BR>> > serverul nu se blocheaza ( serverul poate trimite<BR>> > toate cele 5 cereri, iar threadul respectiv le<BR>> > trateaza secvential)<BR>> > Partea de asincronism este impusa numai pentru<BR>> > celelalte doua tipuri de threaduri. Dar, ca raspuns<BR>> > la intrebarea ta asincronismul implica apeluri<BR>> > neblocante.<BR>> ><BR>> > Toma Monica wrote:<BR>> ><BR>> >
Buna, am si eu cateva nelamuriri, si desi risc sa<BR>> > par<BR>> > stupida, nu am gasit pe nimeni care sa poate sa imi<BR>> > fie de ajutor...<BR>> > Iata care sunt problemele mele:<BR>> ><BR>> > 1. sa presupunem ca avem 5 clienti care se se<BR>> > conecteaza la server pt a cere un ls, iar serverul<BR>> > dispune doar de un thread care face aceasta<BR>> > operatie.<BR>> > Eu am ales ca serverul ( thread-ul principal) sa<BR>> > comunica cu thread-urile worker (prin care executa<BR>> > operatiile) folosind pipe-uri. Ideea e ca citirea de<BR>> > pe pipe am facut-o cu read(blocant) adica un thread<BR>> > worker al serverului isi verifica pipe-ul si dc are<BR>> > operatie o citeste de pe pipe si o executa, deci un<BR>> > thread va putea executa la un moment dat numai o<BR>> > operatie din cele care ii sunt asignate de server -><BR>> > contravine aceasta metoda cu ideea de
asincron?<BR>> > Revenind la cei 5 clienti, dupa ce se obtine<BR>> > rezultatul listarii, acesta trebuie trimis la<BR>> > clienti.Rezultatul este memorat pe server intr-un<BR>> > fisier si apoi citit si trimis la client. Trebuie<BR>> > aceasta citire sa fie si ea asincrona?<BR>> ><BR>> > Probabil voi astepta raspuns la aceasta intrebare<BR>> > inainte sa mai inaintez si altele. S-ar putea sa ma<BR>> > lamuresc.<BR>> ><BR>> > Se poate folosi functia sprintf?<BR>> ><BR>> > Da<BR>> ><BR>> ><BR>> ><BR>> > =====<BR>> ><BR>> > I dream of finding myself laughing!<BR>> ><BR>> ><BR>> > __________________________________<BR>> > Do you Yahoo!?<BR>> > New Yahoo! Photos - easier uploading and sharing.<BR>> > http://photos.yahoo.com/<BR>> > _______________________________________________<BR>> > so mailing list<BR>> >
so@atlantis.cs.pub.ro<BR>><BR>> http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so<BR>><BR>> > ---------------------------------<BR>> > Do you Yahoo!?<BR>> > New Yahoo! Photos - easier uploading and sharing<BR>><BR>> =====<BR>><BR>> I dream of finding myself laughing!<BR>><BR>><BR>> __________________________________<BR>> Do you Yahoo!?<BR>> New Yahoo! Photos - easier uploading and sharing.<BR>> http://photos.yahoo.com/<BR>> _______________________________________________<BR>> so mailing list<BR>> so@atlantis.cs.pub.ro<BR>> http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so<BR>><BR>><BR>><BR>> ---------------------------------<BR>> Do you Yahoo!?<BR>> New Yahoo! Photos - easier uploading and sharing<BR><BR>_______________________________________________<BR>so mailing list<BR>so@atlantis.cs.pub.ro<BR>http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so</BLOCKQUOTE><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=21260/*http://photos.yahoo.com">New Yahoo! Photos - easier uploading and sharing</a>
--0-65181631-1070814879=:88262--