[so] nelamurire privind asincr.
George Ciobanu
so@atlantis.cs.pub.ro
Sun, 7 Dec 2003 22:53:39 -0800 (PST)
--0-1649610648-1070866419=:44575
Content-Type: text/plain; charset=us-ascii
In momentul in care se pierde un semnal, sistemul nu are nici o cale sa anunte acest lucru. Asa ca va seta unele campuri din structura aiocb corespunzator.
In momentul in care eroarea returnata e diferita de EINPROGRESS si aio_return va returna -1 inseamna ca notificarea nu a reusit. (fie din cauza pierderii semnalelor, fie din cauza altor erori interne)
Ionut Constandache <ionut_con@yahoo.com> wrote:
Daca se pierde un semnal care notifica terminarea unei
operatii aio e va intoarce aio_error si aio_return?
If the asynchronous operation has completed
unsuccessfully, then the error status, as described
for read(2) , write(2) , and fsync(3C) , is returned.
If the asynchronous I/O operation has not yet
completed, then EINPROGRESS is returned.
Uitandu-ma la read , write si fsync nu mi s-a parut ca
vreo eroare returnata are vreo legatura cu pierderea
unui semnal.
Multam!
--- George Ciobanu wrote:
> Fisierele nu au o lungime maxima
>
> George Ciobanu wrote: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 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?
> >< BR>> 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
> & gt; 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
> >
>
=== message truncated ===
__________________________________
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
--0-1649610648-1070866419=:44575
Content-Type: text/html; charset=us-ascii
<DIV>In momentul in care se pierde un semnal, sistemul nu are nici o cale sa anunte acest lucru. Asa ca va seta unele campuri din structura aiocb corespunzator.</DIV>
<DIV>In momentul in care eroarea returnata e diferita de EINPROGRESS si aio_return va returna -1 inseamna ca notificarea nu a reusit. (fie din cauza pierderii semnalelor, fie din cauza altor erori interne)<BR><BR><B><I>Ionut Constandache <ionut_con@yahoo.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Daca se pierde un semnal care notifica terminarea unei<BR>operatii aio e va intoarce aio_error si aio_return? <BR><BR>If the asynchronous operation has completed<BR>unsuccessfully, then the error status, as described<BR>for read(2) , write(2) , and fsync(3C) , is returned.<BR>If the asynchronous I/O operation has not yet<BR>completed, then EINPROGRESS is returned. <BR><BR>Uitandu-ma la read , write si fsync nu mi s-a parut ca<BR>vreo eroare returnata are vreo legatura cu pierderea<BR>unui semnal.<BR><BR>Multam!<BR><BR><BR>--- George Ciobanu <CDANGEORGE@YAHOO.COM>wrote:<BR>> Fisierele nu au o lungime maxima<BR>> <BR>> George Ciobanu <CDANGEORGE@YAHOO.COM>wrote:Salut, <BR>> <BR>> 1. In cazul temei veti folosi notificarea prin<BR>> semnale. Ce era in paranteze era o observatie ...<BR>> Aveti grija ca se pot pierde semnale. In acest caz<BR>> eroarea (returnata de
aio_error) este setata in mod<BR>> corespunzator iar aio_return va returna -1. <BR>> 2. Ramane la alegerea ta cum rezolvi aceasta<BR>> problema. (Daca spargi in bucati ,cel mai simplu ar<BR>> fi sa citesti cate o bucata si sa o scrii. )<BR>> Rezolvarea tb specificata in README<BR>> <BR>> <BR>> Cristian Zamfir <ZAMFIR@FX.RO>wrote:<BR>> On Sunday 07 December 2003 17:23, George Ciobanu<BR>> wrote:<BR>> <BR>> Nedumeriri:<BR>> <BR>> a) Sa inteleg din raspunsul la intrebarea 1 ca putem<BR>> sa folosim optiunea cu <BR>> SIGEV_THREAD pentru threadurile de tip a). In cazul<BR>> asta vad ca se creeaza un <BR>> thread nou si nu stiu daca mai e nevoie de semnale,<BR>> cum e precizat in enuntul <BR>> temei.<BR>> <BR>> <BR>> 'struct sigevent aio_sigevent'<BR>> This element specifies how the calling process is<BR>> notified<BR>> once the operation terminates. If the `sigev_notify'<BR>> element<BR>> is `SIGEV_NONE',
no notification is sent. If it is<BR>> `SIGEV_SIGNAL', the signal determined by<BR>> `sigev_signo' is<BR>> sent. Otherwise, `sigev_notify' must be<BR>> `SIGEV_THREAD'. In<BR>> this case, a thread is created which starts<BR>> executing the<BR>> function pointed to by `sigev_notify_function'.<BR>> <BR>> b) In enunt nu se precizeaza daca fisierele au o<BR>> lungime maxima, iar in caz ca <BR>> se poate orice lungime, care e politica care trebuie<BR>> implementata? <BR>> Sa ziceam ca avem de facut aio_read, si avind in<BR>> vedere ca nu se stie ordinea <BR>> in care sunt solutionate cererile AIO, este posibil<BR>> ca pachetele sa ajunga in <BR>> alta ordine la client si unul dintre server si<BR>> client ar trebui sa <BR>> reinventeze partea din tcp legata de reordonarea<BR>> pachetelor.<BR>> Daca asteptam sa se execute aio_read pentru fiecare<BR>> bucatica din fisierul <BR>> cerut, si apoi facem un aio_read pentru
urmatoarea<BR>> bucatica, se complica <BR>> implementarea cozii sau pipe-ului pentru comunicarea<BR>> intre worker-thread-uri <BR>> si threadul principal al serverului.<BR>> <BR>> Multumesc<BR>> <BR>> <BR>> <BR>> > Toma Monica wrote:<BR>> ><BR>> > Multumesc de raspuns, insa mai sunt ceva pb care<BR>> mi-au<BR>> > ramas neclare :).<BR>> ><BR>> > 1. Practic thread-urile worker vor trata cererile<BR>> 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<BR>> loc dai accept cererile vor fi<BR>> > secventializate oricum. Cererile nu sunt tratate<BR>> secevential; ele vor fi<BR>> > pornite de folosind operatii operatii asincrone.<BR>> Daca se termina mai multe<BR>> > in acelasi timp poti sa secventializezi<BR>> raspunsurile ( desi pe linux, daca<BR>>
> folosesti notificare folosind thread-uri ar putea<BR>> raspunde chiar ele)<BR>> ><BR>> ><BR>> ><BR>> > 2. Thread-urile de tip a/b trebuie sa poata sa<BR>> 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<BR>> 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>> & gt; executa?<BR>> ><BR>> ><BR>> > Crearea lor se face la inceput. Oprirea lor se<BR>> face numai atunci cand se<BR>> > opreste serverul (deci, in cazul nostru cam<BR>> 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<BR>> ok<BR>> > > ca threadul de tip ls sa poata prelua numai o<BR>> > > operatie la un moment dat, dar tb sa te asiguri<BR>> ca<BR>> > > serverul nu se blocheaza ( serverul poate<BR>> 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<BR>> 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<BR>> sa<BR>> > > par<BR>> > > stupida, nu am gasit pe nimeni care sa poate sa<BR>> 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<BR>> 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<BR>> executa<BR>> > > operatiile) folosind pipe-uri. Ideea e ca<BR>> citirea de<BR>> > > pe pipe am facut-o cu read(blocant) adica un<BR>> thread<BR>> > > worker al serverului isi verifica pipe-ul si dc<BR>> are<BR>> > > operatie o citeste de pe pipe si o executa, deci<BR>> un<BR>> > > thread va putea executa la un moment dat numai o<BR>> > >
operatie din cele care ii sunt asignate de<BR>> 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<BR>> intr-un<BR>> > > fisier si apoi citit si trimis la client.<BR>> Trebuie<BR>> > > aceasta citire sa fie si ea asincrona?<BR>> > ><BR>> > > Probabil voi astepta raspuns la aceasta<BR>> intrebare<BR>> > > inainte sa mai inaintez si altele. S-ar putea sa<BR>> 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<BR>> sharing.<BR>> > > http://photos.yahoo.com/<BR>> > > _______________________________________________<BR>> > > so mailing list<BR>> > > so@atlantis.cs.pub.ro<BR>> ><BR>> ><BR>><BR>http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so<BR>> ><BR>> <BR>=== message truncated ===<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</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-1649610648-1070866419=:44575--