From so@atlantis.cs.pub.ro Mon Dec 1 01:01:22 2003 From: so@atlantis.cs.pub.ro (Daniel Cosmin Porumbel) Date: Sun, 30 Nov 2003 17:01:22 -0800 Subject: [so] upload mistake Message-ID: <001a01c3b7a6$a36a1b40$42c8100a@16.200.66.p16.pub.ro> This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C3B763.94C09440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Salut! Cred ca am facut o greseala la upload. Am vrut sa trimit tema = si nu mi-a primit-o dintr-un motiv oarecare. Apoi cand am vrut s-o = trimit iar, am dat back si n-am mai modificat dropDownListurile si s-a = pus peste tema1 de Windows. Credeti ca se mai poate face ceva ca sa = recuperez fisierele de dinainte? Sper ca nu face overwrite automat.... Toate bune! Dany ------=_NextPart_000_0017_01C3B763.94C09440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Salut!

=20 Cred ca am facut o greseala la upload. Am vrut sa trimit tema si nu mi-a = primit-o dintr-un motiv oarecare. Apoi cand am vrut s-o trimit iar, am = dat back=20 si n-am mai modificat dropDownListurile si s-a pus peste tema1 de = Windows.=20 Credeti ca se mai poate face ceva ca sa recuperez fisierele de dinainte? = Sper ca=20 nu face overwrite automat....

Toate bune!

Dany

------=_NextPart_000_0017_01C3B763.94C09440-- From so@atlantis.cs.pub.ro Mon Dec 1 10:46:11 2003 From: so@atlantis.cs.pub.ro (Daniel Cosmin Porumbel) Date: Mon, 1 Dec 2003 02:46:11 -0800 Subject: [so] barbieri Message-ID: <001e01c3b7f8$56ac2300$42c8100a@16.200.66.p16.pub.ro> This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C3B7B5.47E8AB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Salut! Am gasit o metoda de rezolvare a problemei aceasta, dar mi se pare = cam dubioasa si nu sunt sigur ca e buna. Se foloseste o singura = signalare si trebuie sa scrii cod doar pentru client; intr-un fel = frizerii sun cam neglijati. As vrea sa va stiu cat e de corect... 1.Vine un client. Daca e loc liber de tuns(frizer dormind), GO TO = 4 2.Daca sunt scaune libere se aseaza. Daca nu, pleaca definitiv. 3.Daca toti frizerii lucreaza, astept ca alt client sa iasa din = frizerie(la 5) si astfel sa elibereze un frizer pe care sa il iau. 4.Am prins loc de tuns(sau frizer dormind-gata sa ma tunda), = astept sa fiu tuns 5.Am fost tuns, semnalizez pe unul blocat la 3 sa treaca mai = departe ca acum are frizer liber. Acesta e comportamentul clientului. Comportamentul frizerilor se deduce = din el: La pasul 4 un frizer se scoala sa tunda. La pasul 5 un frizer se culca. Fara sa mai faci nici o sincronizare, poti sa-ti dai seama care frizer = se scoala si care frizer se culca. Tii niste liste de frizeri...=20 Daca cel care se culca la 5 va fi trezit imediat(la 3), atunci nici nu = mai consideri ca se culca. Consideri ca invita un client la tuns. Toate bune! Dany ------=_NextPart_000_001B_01C3B7B5.47E8AB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Salut!

Am gasit = o metoda=20 de rezolvare a problemei aceasta, dar mi se pare cam = dubioasa si=20 nu sunt sigur ca e buna. Se foloseste o singura signalare=20 si trebuie sa scrii cod doar pentru client; intr-un fel frizerii = sun cam=20 neglijati. As vrea sa = va stiu cat e de=20 corect...

1.Vine = un client.=20 Daca e loc liber de tuns(frizer dormind), GO TO 4

2.Daca = sunt scaune=20 libere se aseaza. Daca nu, pleaca definitiv.

3.Daca = toti frizerii=20 lucreaza, astept ca alt client sa iasa din frizerie(la 5) si astfel = sa=20 elibereze un frizer pe care sa il iau.

4.Am = prins loc de=20 tuns(sau frizer dormind-gata sa ma tunda), astept sa fiu = tuns

5.Am = fost tuns,=20 semnalizez pe unul blocat la 3 sa treaca mai departe ca acum are frizer=20 liber.

Acesta e comportamentul clientului. = Comportamentul frizerilor se deduce din = el:

La pasul 4 un frizer se = scoala sa=20 tunda.

La pasul 5 un frizer se = culca.

Fara sa mai faci nici o sincronizare, = poti sa-ti=20 dai seama care frizer se scoala si care frizer se culca. Tii niste liste = de=20 frizeri...

Daca cel care se culca la 5 va fi = trezit=20 imediat(la 3), atunci nici nu mai consideri ca se culca. Consideri = ca=20 invita un client la tuns.

Toate bune!

Dany

------=_NextPart_000_001B_01C3B7B5.47E8AB60-- From so@atlantis.cs.pub.ro Mon Dec 1 17:40:53 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Mon, 1 Dec 2003 19:40:53 +0200 Subject: [so] tema4 Message-ID: <001501c3b832$67b051f0$a99f9ad5@ioana> Intrebarea 1 : in enuntul temei 4 scrie "pentru operatiile asincrone clienti pot sa specifice modul in care sa se faca notificarea terminarii operatiei". Din asta inteleg ca trebui implementate ambele moduri de notificare si ca modul este specificat de client. Asa este? Si daca este asa, un client trebuie sa primeasca inca un argument in linia de comanda care sa spuna ce mod alege? Iar un fir din server ce se ocupa de operatiile de citire/scriere trebuie sa poata sa se ocupe simultan de operatii care au asociate moduri diferite de notificare a terminarii, si deci sa fie notificat diferit de terminarea operatiilor care le-a inceput? Intrebarea 2 : in enunt scrie ca operatiile de citire si scriere din/in fisier se fac in niste fire ale serverului ce se ocupa de asta, dar operatia de listare a fisierelor dintr-un director trebuie si ea facuta intr-unul din aceste fire, sau poate fi facuta in firul principal al serverului? Intrebarea 3 : firele ce se ocupa de operatiile de citire/scriere pot sa trimeata rezultatele la clienti sau ele doar fac citirea/scrierea si firul principal va trimite rezultatele? From so@atlantis.cs.pub.ro Mon Dec 1 18:08:43 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Mon, 1 Dec 2003 10:08:43 -0800 (PST) Subject: [so] tema4 In-Reply-To: <001501c3b832$67b051f0$a99f9ad5@ioana> Message-ID: <20031201180843.97857.qmail@web41009.mail.yahoo.com> --0-1560091613-1070302123=:97255 Content-Type: text/plain; charset=us-ascii Ioana Cutcutache wrote: Intrebarea 1 : in enuntul temei 4 scrie "pentru operatiile asincrone clienti pot sa specifice modul in care sa se faca notificarea terminarii operatiei". Din asta inteleg ca trebui implementate ambele moduri de notificare si ca modul este specificat de client. Asa este? Si daca este asa, un client trebuie sa primeasca inca un argument in linia de comanda care sa spuna ce mod alege? Iar un fir din server ce se ocupa de operatiile de citire/scriere trebuie sa poata sa se ocupe simultan de operatii care au asociate moduri diferite de notificare a terminarii, si deci sa fie notificat diferit de terminarea operatiilor care le-a inceput? Trebuie implementate ambele moduri de notificare, dar in surse separate. Intrebarea 2 : in enunt scrie ca operatiile de citire si scriere din/in fisier se fac in niste fire ale serverului ce se ocupa de asta, dar operatia de listare a fisierelor dintr-un director trebuie si ea facuta intr-unul din aceste fire, sau poate fi facuta in firul principal al serverului? Intrebarea 3 : firele ce se ocupa de operatiile de citire/scriere pot sa trimeata rezultatele la clienti sau ele doar fac citirea/scrierea si firul principal va trimite rezultatele? Serverul face doar load balancing. _______________________________________________ so mailing list so@atlantis.cs.pub.ro http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so --------------------------------- Do you Yahoo!? Free Pop-Up Blocker - Get it now --0-1560091613-1070302123=:97255 Content-Type: text/html; charset=us-ascii

Ioana Cutcutache <ioana_c@pcnet.ro> wrote:

Intrebarea 1 : in enuntul temei 4 scrie "pentru operatiile asincrone
clienti pot sa specifice modul in care sa se faca notificarea terminarii
operatiei". Din asta inteleg ca trebui implementate ambele moduri de
notificare si ca modul este specificat de client. Asa este? Si daca este
asa, un client trebuie sa primeasca inca un argument in linia de comanda
care sa spuna ce mod alege? Iar un fir din server ce se ocupa de operatiile
de citire/scriere trebuie sa poata sa se ocupe simultan de operatii care au
asociate moduri diferite de notificare a terminarii, si deci sa fie
notificat diferit de terminarea operatiilor care le-a inceput?

Trebuie implementate ambele moduri de notificare, dar in surse separate.

Intrebarea 2 : in enunt scrie ca operatiile de citire si scriere din/in
fisier se fac in niste fire ale serverului ce se ocupa de asta, dar operatia
de listare a fisierelor dintr-un director trebuie si ea facuta intr-unul din
aceste fire, sau poate fi facuta in firul principal al serverului?

Intrebarea 3 : firele ce se ocupa de operatiile de citire/scriere pot sa
trimeata rezultatele la clienti sau ele doar fac citirea/scrierea si firul
principal va trimite rezultatele?

Serverul face doar load balancing.

_______________________________________________
so mailing list
so@atlantis.cs.pub.ro
http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so

Do you Yahoo!?
Free Pop-Up Blocker - Get it now --0-1560091613-1070302123=:97255-- From so@atlantis.cs.pub.ro Mon Dec 1 19:21:26 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Mon, 1 Dec 2003 11:21:26 -0800 (PST) Subject: [so] tema4 In-Reply-To: <20031201180843.97857.qmail@web41009.mail.yahoo.com> Message-ID: <20031201192126.19487.qmail@web41009.mail.yahoo.com> --0-1345850905-1070306486=:18479 Content-Type: text/plain; charset=us-ascii Salut, Enuntul temei 4 s-a modificat putin, in sensul ca threadurile de pe server implementeaza citirea/scrierea printr-una din cele doua metode (si numai una). De asemenea, exista threaduri de ambele tipuri (distributia se face in mod egal). Evident raspunsul anterior este inadecvat. George --------------------------------- Do you Yahoo!? Free Pop-Up Blocker - Get it now --0-1345850905-1070306486=:18479 Content-Type: text/html; charset=us-ascii

Salut,

Enuntul temei 4 s-a modificat putin, in sensul ca threadurile de pe server implementeaza citirea/scrierea printr-una din cele doua metode (si numai una). De asemenea, exista threaduri de ambele tipuri (distributia se face in mod egal).

Evident raspunsul anterior este inadecvat.

George

Do you Yahoo!?
Free Pop-Up Blocker - Get it now --0-1345850905-1070306486=:18479-- From so@atlantis.cs.pub.ro Mon Dec 1 23:13:22 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Tue, 02 Dec 2003 01:13:22 +0200 Subject: [so] tema4 In-Reply-To: <001501c3b832$67b051f0$a99f9ad5@ioana> References: <001501c3b832$67b051f0$a99f9ad5@ioana> Message-ID: On Mon, 1 Dec 2003 19:40:53 +0200, Ioana Cutcutache wrote: > Intrebarea 2 : in enunt scrie ca operatiile de citire si scriere > din/in > fisier se fac in niste fire ale serverului ce se ocupa de asta, dar > operatia > de listare a fisierelor dintr-un director trebuie si ea facuta intr-unul > din > aceste fire, sau poate fi facuta in firul principal al serverului? > Se face intr-un thread separat, dedicat. A fost updatat si enuntul pentru claritate. > Intrebarea 3 : firele ce se ocupa de operatiile de citire/scriere > pot sa trimeata rezultatele la clienti ... ? > Pot si este recomandat. tavi From so@atlantis.cs.pub.ro Mon Dec 1 23:38:49 2003 From: so@atlantis.cs.pub.ro (Cibu Cristian) Date: Tue, 2 Dec 2003 01:38:49 +0200 Subject: [so] egal incarcate Message-ID: <001401c3b864$459774e0$0200a8c0@smeagol> This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C3B875.0911ED00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "Serverul trebuie sa se asigure ca thread-urile sunt egal incarcate." Ce inseamna egal incarcate? (nu ma refer la concept). Eu am in minte 2 = variante dar nu le spun pentru ca nu vreau sa dau idei de enunt. :) ------=_NextPart_000_0011_01C3B875.0911ED00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

"Serverul=20 trebuie sa se asigure ca thread-urile sunt egal = incarcate."

Ce inseamna egal incarcate? (nu ma = refer la=20 concept). Eu am in minte 2 variante dar nu le spun pentru ca nu vreau sa = dau=20 idei de enunt. :)

------=_NextPart_000_0011_01C3B875.0911ED00-- From so@atlantis.cs.pub.ro Tue Dec 2 06:35:04 2003 From: so@atlantis.cs.pub.ro (Octavian PURDILA) Date: Tue, 2 Dec 2003 08:35:04 +0200 Subject: [so] egal incarcate In-Reply-To: <001401c3b864$459774e0$0200a8c0@smeagol> References: <001401c3b864$459774e0$0200a8c0@smeagol> Message-ID: <1070346904.3fcc3298b1d24@Apollo.cs.pub.ro> Quoting Cibu Cristian : > "Serverul trebuie sa se asigure ca thread-urile sunt egal incarcate." > > Ce inseamna egal incarcate? (nu ma refer la concept). Eu am in minte 2 > variante dar nu le spun pentru ca nu vreau sa dau idei de enunt. :) > > Inseamna ca thread-urile de acelasi tip trebuie sa aiba un numar egal de cereri de procesat. La sosirea unei cereri, serverul va verifica care din thread-uri are cele mai putine cereri de procesat si va da cererea spre procesare thread-udului respectiv. tavi ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From so@atlantis.cs.pub.ro Tue Dec 2 08:32:42 2003 From: so@atlantis.cs.pub.ro (Ovidiu Platon) Date: Tue, 2 Dec 2003 10:32:42 +0200 Subject: [so] egal incarcate Message-ID: <36C8164AE0C6CA4987C3EC88A1BB416A014713@server.microsoft-lab.pub.ro> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B8AE.DA97EC29 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ImRpbnRyLXVuIG51bWFyIGxpbWl0YXQgZGUgdGhyZWFkLXVyaSwgc3BlY2lmaWNhdCBsYSBwb3Ju aXJlYSBzZXJ2ZXJ1bHVpIGluIGxpbmlhIGRlIGNvbWFuZGEiDQpFc3RlIG5lYXBhcmF0IG5lY2Vz YXIgY2EgbnVtYXJ1bCBkZSB0aHJlYWR1cmkgc2EgZmllIGxpbWl0YXQgc2kgdHJlYnVpZSBuZWFw YXJhdCBzYSBhdmVtIDIgY2xhc2UgZGUgdGhyZWFkdXJpPyBQZSBXaW5kb3dzLCBjZWwgcHV0aW4s IHN1cG9ydHVsIHNpc3RlbXVsdWkgZGUgb3BlcmFyZSBwdCB0aHJlYWQgcG9vbGluZyBjb21iaW5h dCBjdSBvcGVyYXRpaSBhc2luY3JvbmUgZGUgSS9PIGVzdGUgZGVsb2MgZGUgbmVnbGlqYXQgc2kg YXIgYWp1dGEgZGVzdHVsIGRlIG11bHQgbGEgaW1idW5hdGF0aXJlYSBzY2FsYWJpbGl0YXRpaSAo c2F1LCBjdSBhbHRlIGN1dmludGUsIGNlIG1hIHN1cGFyYSBwZSBtaW5lIGUgY2EgdHJlYnVpZSBz YSByZWludmVudGFtIHJvYXRhKS4gRSBkcmVwdCwgYXN0YSBhciBjYW0gZWxpbWluYSBjZXJpbnRh IGRlIGEgaW1wbGVtZW50YSAyIGNsYXNlIGRpZmVyaXRlIGRlIHRocmVhZHVyaSAoY2l0aXJlL3Nj cmllcmUgc2kgbGlzdGFyZSksIGRhciBpbXBsZW1lbnRhcmVhIGFyIGZpIG1haSByZXVzaXRhIGNh IHBlcmZvcm1hbnRhIHNpIHNjYWxhYmlsaXRhdGUuDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLSANCglGcm9tOiBPY3RhdmlhbiBQVVJESUxBIFttYWlsdG86dGF2aUBjcy5wdWIucm9dIA0K CVNlbnQ6IFR1ZSAxMi8yLzIwMDMgODozNSBBTSANCglUbzogc29AYXRsYW50aXMuY3MucHViLnJv IA0KCUNjOiANCglTdWJqZWN0OiBSZTogW3NvXSBlZ2FsIGluY2FyY2F0ZQ0KCQ0KCQ0KDQoJUXVv dGluZyBDaWJ1IENyaXN0aWFuIDxjaWJ1LmNyaXN0aWFuQHJkc2xpbmsucm8+Og0KCQ0KCT4gIlNl cnZlcnVsIHRyZWJ1aWUgc2Egc2UgYXNpZ3VyZSBjYSB0aHJlYWQtdXJpbGUgc3VudCBlZ2FsIGlu Y2FyY2F0ZS4iDQoJPg0KCT4gQ2UgaW5zZWFtbmEgZWdhbCBpbmNhcmNhdGU/IChudSBtYSByZWZl ciBsYSBjb25jZXB0KS4gRXUgYW0gaW4gbWludGUgMg0KCT4gdmFyaWFudGUgZGFyIG51IGxlIHNw dW4gcGVudHJ1IGNhIG51IHZyZWF1IHNhIGRhdSBpZGVpIGRlIGVudW50LiA6KQ0KCT4NCgk+DQoJ DQoJSW5zZWFtbmEgY2EgdGhyZWFkLXVyaWxlIGRlIGFjZWxhc2kgdGlwIHRyZWJ1aWUgc2EgYWli YSB1biBudW1hciBlZ2FsDQoJZGUgY2VyZXJpIGRlIHByb2Nlc2F0LiBMYSBzb3NpcmVhIHVuZWkg Y2VyZXJpLCBzZXJ2ZXJ1bCB2YSB2ZXJpZmljYSBjYXJlDQoJZGluIHRocmVhZC11cmkgYXJlIGNl bGUgbWFpIHB1dGluZSBjZXJlcmkgZGUgcHJvY2VzYXQgc2kgdmEgZGEgY2VyZXJlYSBzcHJlDQoJ cHJvY2VzYXJlIHRocmVhZC11ZHVsdWkgcmVzcGVjdGl2Lg0KCQ0KCXRhdmkNCgkNCgkNCgkNCgkN CgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhp cyBtYWlsIHNlbnQgdGhyb3VnaCBJTVA6IGh0dHA6Ly9ob3JkZS5vcmcvaW1wLw0KCV9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJc28gbWFpbGluZyBsaXN0 DQoJc29AYXRsYW50aXMuY3MucHViLnJvDQoJaHR0cDovL2F0bGFudGlzLmNzLnB1Yi5yby9jZ2kt YmluL21haWxtYW4vbGlzdGluZm8vc28NCgkNCg0K ------_=_NextPart_001_01C3B8AE.DA97EC29 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IisIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA4gQAAAAAAADmAAENgAQAAgAAAAIAAgABBYAD AA4AAADTBwwAAgAKACAAKgACAD4BASCAAwAOAAAA0wcMAAIACgAgACoAAgA+AQEJgAEAIQAAADM4 QTU1RTgxREI4NzAzNEM5RDU1NDM1NDM5QzQ2OTIzAAEHAQOQBgBQEQAAOAAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAADAAAABSAEUAOgAgAFsAcwBvAF0A IABlAGcAYQBsACAAaQBuAGMAYQByAGMAYQB0AGUAAABAADkAKeyX2q64wwEfAD0AAQAAAAoAAABS AEUAOgAgAAAAAAACAUcAAQAAACsAAABjPXVzO2E9IDtwPU1TTGFiO2w9U0VSVkVSLTAzMTIwMjA4 MzI0MlotMzMAAB8ASQABAAAAMAAAAFIAZQA6ACAAWwBzAG8AXQAgAGUAZwBhAGwAIABpAG4AYwBh AHIAYwBhAHQAZQAAAEAATgAA3DxrnrjDAR8AWgABAAAAIgAAAE8AYwB0AGEAdgBpAGEAbgAgAFAA VQBSAEQASQBMAEEAAAAAAAIBWwABAAAAPQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE9jdGF2 aWFuIFBVUkRJTEEAU01UUAB0YXZpQGNzLnB1Yi5ybwAAAAACAVwAAQAAABQAAABTTVRQOlRBVklA Q1MuUFVCLlJPAB8AXQABAAAAIgAAAE8AYwB0AGEAdgBpAGEAbgAgAFAAVQBSAEQASQBMAEEAAAAA AAIBXgABAAAAPQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE9jdGF2aWFuIFBVUkRJTEEAU01U UAB0YXZpQGNzLnB1Yi5ybwAAAAACAV8AAQAAABQAAABTTVRQOlRBVklAQ1MuUFVCLlJPAB8AZgAB AAAACgAAAFMATQBUAFAAAAAAAB8AZwABAAAAHgAAAHQAYQB2AGkAQABjAHMALgBwAHUAYgAuAHIA bwAAAAAAHwBoAAEAAAAKAAAAUwBNAFQAUAAAAAAAHwBpAAEAAAAeAAAAdABhAHYAaQBAAGMAcwAu AHAAdQBiAC4AcgBvAAAAAAAfAHAAAQAAACgAAABbAHMAbwBdACAAZQBnAGEAbAAgAGkAbgBjAGEA cgBjAGEAdABlAAAAAgFxAAEAAAAbAAAAAcO4ngyG9kl+rba6SAK+vB/MHPGflwADvoJsAB8AdAAB AAAALAAAAHMAbwBAAGEAdABsAGEAbgB0AGkAcwAuAGMAcwAuAHAAdQBiAC4AcgBvAAAAHwAaDAEA AAAcAAAATwB2AGkAZABpAHUAIABQAGwAYQB0AG8AbgAAAB8AHQ4BAAAAKAAAAFsAcwBvAF0AIABl AGcAYQBsACAAaQBuAGMAYQByAGMAYQB0AGUAAAACAQkQAQAAAGIJAABeCQAAWBwAAExaRnVWvw0v AwAKAHJjcGcxMjWCMgNDaHRtbDEDMD8BAwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYI VQeyEdUOUQMB3RDXMgYABsMR1TMERhDZbxLrEeMI7wn3OxjPDjA1OxHSDGBjAFALCQFkMzaTEWAL pTQgEAIqXA6yvQGQZxTwCqMR4x3oNBTwADwhRE9DVFlQAEUgSFRNTCBQAFVCTElDICItIC8vVzND IYBEVCJEIJQzLjIhgEVOnCI+Hu0ejyPBMTgf8G8goiMPJB8mkDMdgCVwRXxBRCXNDvEm7ylvJPQ2 QQ7wPE1FVEEHsEExLGA9IkcJ8ASQYXRFBbAiEtBPTlQi0FQTLPAF4UV4EPFuZ2U9BlJ2EzEvQQCQ AiAgNhAuMC42HXA5LjEnIv4qzyUDNzcf8FRJKFRMRSXONA7wUmUAOiBbc29dIGVqZwdAIAuAYwrA NcB06mUkbjUf8C8zTzF/JkVfNJE3UChPJp87JDURYDwAQk9EWSBkaXL6PTtAcjqQOwMAIQMwPaGc ZG8A4D2hCrFccRiw/z2hEPADMD4FEWA6uxzxO7+IZzk2H/BESVY92WcAAEAXOtk2NENPQGIiIz1g AjByLXUDoG516wDABcBsB3BpAZAFQAEAyCB0aBjQYWRHEAUQ8Cwgc3AFkAaQDeBIAfkLYCBwBbAD AEiBSRAvI/p1CkBpNZEdnB2AQZRHsB8DAEngSDEFoAOBZGEifzrZAcA95wqiPecKcSR8MP8oESHg QxtPeECfQa9Cv0PP80TfVhtFczYQR0BIkAqx+0gBLTBjB5AKwTXAR0RK8P9IKAhxSRBJ4ElwLvBH tgCQ+0hQGNBiSxAu8Et/VAJZV6Vb4WEvQG0gFPBjC2DbETBbCz8g4C7wVwuAPsAcd3NJAFoAAyBw dXTrC4BJAXVKAXRa4V2PVALbAJBZEW1K80gxb0kwLVB/GNBJ8AVASGRJ8QbwC4BnzU1CYguASAFj dWVkYmA/SyBgIDWhA2AtMEgiSS9+T2M/U/MHkFkhAQAYYGNrSCItMGdHsGpcpArBYSpqYlBhOrs4 HYAmbs5iSSACgD34J2EBQFJn7wEAWRBa5GThdGzvbf9vCv9J0QdwXTBnYWgRSlJpf2RTvzXAC2Bn QEewdBJLIChaIL51YeFnsAdAWSFnoHZG0f5lYeJwUEpxYsBZkUnwcEH/C4Au8E0xSeBdBlvhdJ9U Au8Y0AuAL0ACMGFfwANgdAH8KS4ucD1QGNAFMEkAYCD/AZBsUjXAX8BiEEfBZ2Bh8f8FEHxBSCJz kgtQX7B8MnCv/3G/bwoU8HqfVAJgBQaQBnHbauNbOShJUHQyLwTyBJDfekFLIEewfbEY0ClJAE2g /wXAf7hKUgrBSXCDT1PzAMD7SyAY0HUAkH3BWmFlgQIQnnIDgX3BXNF16mUuTd9/Tu9P/1EPUh9T L1Q/PQBM4SAwS1FVTy3wPVZJEAx0eX/gLjFBUkdJYE4tUklHIKA04DD8cHgi8T34CrEQAj8FP6P/ P2E//5NPHxsRYJ0glC9VT29WX1dvmkc+gGkc0iR8NK0lUUYt0VzBepawMp6rqwvimiktpiJPBRBn Z1H9AyBNB5BaIC7gpiOijSwQ/TzxUj3beVEKgZpPgNY9ANWeq2KaKUYDYTqdbB/hxi+r6pI5IE9j AZB30OsDkSDwUp5wTCyQib+b75uBIZ0xW4sBO0BvOrCSkEBjcy5iQGIuA2D/NTCn36jvqf+rD6wf uCQGYK8CMK3Prt+v51QKUCAOIAIvvnEwMDMgODr+MzcwLMC1f7aPt5+4r7m//cIVVLRgu4+8n6/2 sY+yn3uzpDUQQC1gC2ACMAQALn+0179/wI/Bn8Kvw7/OdUP+Y8Vfxm/Hf8xvzX/Oj8+f+7pOtRBq BZC7b9K/r9g0zP/ID8kfs6Q1p9Rv1X/Wj+Ff1+Jv438k1jWeQS+jstvP/5++jn+Pj5Cf6L+ar97/ nM/7oFYf8FCYD6GJoP+iD6MfY6QvpT1RdW9iYWbwQ/5pXTAS0AUQWRCwwt4f8C/vs6SAXztAgak8 7nhJUF0wq8sw+pVACyBzTMFrtTH1/Z9n/ro+7njajOT/5g+/5B8FTwZfAc8C37AUIi8U71rheelg MWhhZxMAXW/8D3+zhnmySHd/4GKhu1A1TS7+IgdPCF8Jbwp/C48WfxSP7xWfFq8Xv6/nQy7wfqBg MH98YH6x3c8Pr9/vNgFhICj/R1B4YnvghSFJwk1QNbB9Ub984ndBX8BLQX6RWSEyGU/fGl8bbxx/ HY+wI3ZsYPrR/2ribGEjMR//IQ/9NBIyYkD/RzBJMEbhZ7BaYytQSIFnsPd6YU2gZ7BpaxBlI7tA EnHPfPAsby1//TQ6KSXPJt//J+8o/yoPN181bzZ/N484n388rzq/O88/b0B/QY/u8Ek/HyYRbn9i YgFoYUZgaXDXed8yTzNffYsQYiNwLzH/WpMfk0K/Q89B3IWRfuF+8V2FgnBosFoCMcFMjJFv/2hw dFIvMDEhT7RikQ0GSO//Sf/9NCtgK1B+8YmAL9Hgsf/hH02PTp4lIUZ4bFFPkhIx/4sCYkNPn1Ch bCJTD1QfVSf/iDBbpHRhgYBWb1d/Qb5QVfdlwUZ2hhBsSHBdD14fs5XHe+CBgNpRaXYuYL9hz/9B 32iPaZ9qqbCSa19sb2p//27Pb99w73H/cw90H3Uvdj//d094X3lvpgV9337vf5h6n/N7r3m8VGiH oGUvZj+zlQ+0Eg4hEoFGcW91Z2j5RaBNUJeg12+xYITj/VANZGFmlsD+8HRwOi8sL2iMMDEQLoww Zy9waW1wL5f6+KFIgGwaZPCCZoxAHxF0e0igWVBFUkyXIEsM0LOJ74rzfX34oYxAcgEgwHRcY2Yx XA1Refi/jd+K8u3f9Erub9r6QYHg94Cvgb95vF+ZL5o/mwqWL/+XP3m8yoCD74T/hgn58nmQ//qw nB+dL54+yq8BjaNfpG8Ph9+I75EUpb9vL2Nn6GktYiUgL4ZyhnCt0PuiQiUgZq1QpYCLP4xPjV3/ rE+tX65rjz+QT7Ifsy+uTP+Tn5NvqX+Vj6dPqF+8X+fP/7uv9GfrXvLvwJ/qZNuB8rED7F/bkUxP Q0tRVfhPVEXCj8av79/L//CnxjX3EdugT0RZvf3bcAvNv/ERN9uBSFRNTAW/UH3ScAAAHwA1EAEA AACKAAAAPAAzADYAQwA4ADEANgA0AEEARQAwAEMANgBDAEEANAA5ADgANwBDADMARQBDADgAOABB ADEAQgBCADQAMQA2AEEAMAAxADQANwAxADMAQABzAGUAcgB2AGUAcgAuAG0AaQBjAHIAbwBzAG8A ZgB0AC0AbABhAGIALgBwAHUAYgAuAHIAbwA+AAAAAAAfAEcQAQAAAB4AAABtAGUAcwBzAGEAZwBl AC8AcgBmAGMAOAAyADIAAAAAAAsA8hABAAAAHwDzEAEAAAA8AAAAUgBFACUAMwBBACAAWwBzAG8A XQAgAGUAZwBhAGwAIABpAG4AYwBhAHIAYwBhAHQAZQAuAEUATQBMAAAACwD2EAAAAABAAAcwY6qO Bq24wwFAAAgw69ej2q64wwEDAN4/6f0AAAMA8T8JBAAAHwD4PwEAAAAcAAAATwB2AGkAZABpAHUA IABQAGwAYQB0AG8AbgAAAAIB+T8BAAAAXQAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAv Tz1NU0xBQi9PVT1GSVJTVCBBRE1JTklTVFJBVElWRSBHUk9VUC9DTj1SRUNJUElFTlRTL0NOPU9W SURJVVBMAAAAAB8A+j8BAAAAKgAAAFMAeQBzAHQAZQBtACAAQQBkAG0AaQBuAGkAcwB0AHIAYQB0 AG8AcgAAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/ 5AQAAAMAGUAAAAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHwAwQAEAAAASAAAATwBWAEkARABJ AFUAUABMAAAAAAAfADFAAQAAABIAAABPAFYASQBEAEkAVQBQAEwAAAAAAB8AMkABAAAAHgAAAHQA YQB2AGkAQABjAHMALgBwAHUAYgAuAHIAbwAAAAAAHwAzQAEAAAAeAAAAdABhAHYAaQBAAGMAcwAu AHAAdQBiAC4AcgBvAAAAAAAfADhAAQAAABIAAABPAFYASQBEAEkAVQBQAEwAAAAAAB8AOUABAAAA BAAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGEJHEEwsDAAcQBQUAAAMAEBAAAAAAAwAREAAAAAAe AAgQAQAAAGUAAAAiRElOVFItVU5OVU1BUkxJTUlUQVRERVRIUkVBRC1VUkksU1BFQ0lGSUNBVExB UE9STklSRUFTRVJWRVJVTFVJSU5MSU5JQURFQ09NQU5EQSJFU1RFTkVBUEFSQVRORUNFU0FSAAAA AAIBfwABAAAARQAAADwzNkM4MTY0QUUwQzZDQTQ5ODdDM0VDODhBMUJCNDE2QTAxNDcxM0BzZXJ2 ZXIubWljcm9zb2Z0LWxhYi5wdWIucm8+AAAAAPo/ ------_=_NextPart_001_01C3B8AE.DA97EC29-- From so@atlantis.cs.pub.ro Tue Dec 2 10:39:50 2003 From: so@atlantis.cs.pub.ro (Cibu Cristian) Date: Tue, 2 Dec 2003 12:39:50 +0200 Subject: [so] apc vs WaitFor Message-ID: <001001c3b8c0$9cf3a270$0200a8c0@smeagol> This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C3B8D1.606E41A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable este ok daca din functia callback (in cazul a) nu facem altceva decat un = SetEvent(event), unde "event" ar fi fost cel din cazul b ? ------=_NextPart_000_000D_01C3B8D1.606E41A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

este ok daca din functia callback (in = cazul a) nu=20 facem altceva decat un SetEvent(event), unde "event" ar fi fost cel din = cazul b=20 ?

------=_NextPart_000_000D_01C3B8D1.606E41A0-- From so@atlantis.cs.pub.ro Tue Dec 2 11:22:05 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Tue, 2 Dec 2003 03:22:05 -0800 (PST) Subject: [so] apc vs WaitFor In-Reply-To: <001001c3b8c0$9cf3a270$0200a8c0@smeagol> Message-ID: <20031202112205.55840.qmail@web41003.mail.yahoo.com> --0-972166508-1070364125=:55801 Content-Type: text/plain; charset=us-ascii NU Cibu Cristian wrote:este ok daca din functia callback (in cazul a) nu facem altceva decat un SetEvent(event), unde "event" ar fi fost cel din cazul b ? --------------------------------- Do you Yahoo!? Free Pop-Up Blocker - Get it now --0-972166508-1070364125=:55801 Content-Type: text/html; charset=us-ascii

NU

Cibu Cristian <cibu.cristian@rdslink.ro> wrote:

este ok daca din functia callback (in cazul a) nu facem altceva decat un SetEvent(event), unde "event" ar fi fost cel din cazul b ?

Do you Yahoo!?
Free Pop-Up Blocker - Get it now --0-972166508-1070364125=:55801-- From so@atlantis.cs.pub.ro Tue Dec 2 15:13:59 2003 From: so@atlantis.cs.pub.ro (Octavian PURDILA) Date: Tue, 2 Dec 2003 17:13:59 +0200 Subject: [so] egal incarcate In-Reply-To: <36C8164AE0C6CA4987C3EC88A1BB416A014713@server.microsoft-lab.pub.ro> References: <36C8164AE0C6CA4987C3EC88A1BB416A014713@server.microsoft-lab.pub.ro> Message-ID: <1070378039.3fccac37acf05@Apollo.cs.pub.ro> Quoting Ovidiu Platon : > "dintr-un numar limitat de thread-uri, specificat la pornirea serverului in > linia de comanda" > Este neaparat necesar ca numarul de threaduri sa fie limitat si trebuie > neaparat sa avem 2 clase de threaduri? > Ce semnificatie ti se pare ca are cuvantul "trebuie"? > Pe Windows, cel putin, suportul > sistemului de operare pt thread pooling combinat cu operatii asincrone de I/O > este deloc de neglijat si ar ajuta destul de mult la imbunatatirea > scalabilitatii (sau, cu alte cuvinte, ce ma supara pe mine e ca trebuie sa > reinventam roata). > Cu ce te ajuta ma rog la scalabilitatea sistemului faptul ca ai 1, 2 sau 10 thread-uri in momentul in care thread-urile stau si asteapta completarea a sa zicem 10 operatii de I/O? tavi ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From so@atlantis.cs.pub.ro Tue Dec 2 15:50:20 2003 From: so@atlantis.cs.pub.ro (Ovidiu Platon) Date: Tue, 2 Dec 2003 17:50:20 +0200 Subject: [so] egal incarcate In-Reply-To: <1070378039.3fccac37acf05@Apollo.cs.pub.ro> Message-ID: -----Original Message----- From: so-admin@atlantis.cs.pub.ro [mailto:so-admin@atlantis.cs.pub.ro] On Behalf Of Octavian PURDILA Sent: Tuesday, December 02, 2003 5:14 PM To: so@atlantis.cs.pub.ro Subject: RE: [so] egal incarcate Quoting Ovidiu Platon : > "dintr-un numar limitat de thread-uri, specificat la pornirea > serverului in linia de comanda" > Este neaparat necesar ca numarul de threaduri sa fie limitat si > trebuie neaparat sa avem 2 clase de threaduri? > Ce semnificatie ti se pare ca are cuvantul "trebuie"? OP> Nu stiu, dar o sa ma gandesc... Duh... > Pe Windows, cel putin, suportul > sistemului de operare pt thread pooling combinat cu operatii asincrone > de I/O este deloc de neglijat si ar ajuta destul de mult la > imbunatatirea scalabilitatii (sau, cu alte cuvinte, ce ma supara pe > mine e ca trebuie sa reinventam roata). > Cu ce te ajuta ma rog la scalabilitatea sistemului faptul ca ai 1, 2 sau 10 thread-uri in momentul in care thread-urile stau si asteapta completarea a sa zicem 10 operatii de I/O? OP> E simplu, daca ai numarul de threaduri limitat la 10 si toate 10 asteapta pe I/O, al 11-lea client va primi "Server Too Busy". Daca ai numar nelimitat de threaduri (tunat dinamic de sistem, in functie de incarcarea de pe procesoare, statistica de Context Switches, si tot ce mai face un sistem de operare decent intern), mai trebuie sa limitezi doar lungimea cozii de requesturi neprocesate inca (pending) - care poate fi de ordinul miilor sau zecilor de mii. Eu zic ca ajuta daca incerci sa vinzi o aplicatie server, dar ma rog, am impresia ca aici invatam, nu gandim :) tavi ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ so mailing list so@atlantis.cs.pub.ro http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so From so@atlantis.cs.pub.ro Tue Dec 2 22:24:40 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Wed, 03 Dec 2003 00:24:40 +0200 Subject: [so] egal incarcate In-Reply-To: References: Message-ID: On Tue, 2 Dec 2003 17:50:20 +0200, Ovidiu Platon wrote: > > Ce semnificatie ti se pare ca are cuvantul "trebuie"? > > OP> Nu stiu, dar o sa ma gandesc... Duh... > Care parte din "trebuie" nu o intelegi? >> Pe Windows, cel putin, suportul >> sistemului de operare pt thread pooling combinat cu operatii asincrone >> de I/O este deloc de neglijat si ar ajuta destul de mult la >> imbunatatirea scalabilitatii (sau, cu alte cuvinte, ce ma supara pe >> mine e ca trebuie sa reinventam roata). >> > > Cu ce te ajuta ma rog la scalabilitatea sistemului faptul ca ai 1, 2 > sau 10 > thread-uri in momentul in care thread-urile stau si asteapta completarea > a sa zicem 10 operatii de I/O? > > OP> E simplu, daca ai numarul de threaduri limitat la 10 si toate 10 > asteapta pe I/O, al 11-lea client va primi "Server Too Busy". Daca ai Threadul trebuie sa poata primi cereri noi atat timp cat asteapta rezultatul de la celelate cereri... Deci, supriza, al 11-lea client nu va primi "server too busy", ci "i am ready to rock". > numar nelimitat de threaduri (tunat dinamic de sistem, in functie de > incarcarea de pe procesoare, statistica de Context Switches, si tot ce > mai face un sistem de operare decent intern), mai trebuie sa limitezi > doar lungimea cozii de > requesturi neprocesate inca (pending) - care poate fi de ordinul miilor > sau zecilor de mii. Eu zic ca ajuta daca incerci sa vinzi o aplicatie > server, > dar ma rog, am impresia ca aici invatam, nu gandim :) > Mie nu mi se pare nici ca gandesti, nici ca vrei sa inveti ceva. tavi From so@atlantis.cs.pub.ro Wed Dec 3 08:29:20 2003 From: so@atlantis.cs.pub.ro (Ovidiu Platon) Date: Wed, 3 Dec 2003 10:29:20 +0200 Subject: [so] egal incarcate Message-ID: <36C8164AE0C6CA4987C3EC88A1BB416A014717@server.microsoft-lab.pub.ro> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B977.8C981FD4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogT2N0YXZpYW4gUHVyZGls YSBbbWFpbHRvOnRhdmlAY3MucHViLnJvXSANCglTZW50OiBXZWQgMTIvMy8yMDAzIDEyOjI0IEFN IA0KCVRvOiBzb0BhdGxhbnRpcy5jcy5wdWIucm8gDQoJQ2M6IA0KCVN1YmplY3Q6IFJlOiBbc29d IGVnYWwgaW5jYXJjYXRlDQoJDQoJDQoNCglPbiBUdWUsIDIgRGVjIDIwMDMgMTc6NTA6MjAgKzAy MDAsIE92aWRpdSBQbGF0b24NCgk8b3ZpZGl1cGxAbWljcm9zb2Z0LWxhYi5wdWIucm8+IHdyb3Rl Og0KCQ0KCT4NCgk+IENlIHNlbW5pZmljYXRpZSB0aSBzZSBwYXJlIGNhIGFyZSBjdXZhbnR1bCAi dHJlYnVpZSI/DQoJPg0KCT4gT1A+IE51IHN0aXUsIGRhciBvIHNhIG1hIGdhbmRlc2MuLi4gRHVo Li4uDQoJPg0KCQ0KCUNhcmUgcGFydGUgZGluICJ0cmVidWllIiBudSBvIGludGVsZWdpPw0KDQoJ T1A+IFByaW1hLi4uDQoJDQoJPj4gUGUgV2luZG93cywgY2VsIHB1dGluLCBzdXBvcnR1bA0KCT4+ IHNpc3RlbXVsdWkgZGUgb3BlcmFyZSBwdCB0aHJlYWQgcG9vbGluZyBjb21iaW5hdCBjdSBvcGVy YXRpaSBhc2luY3JvbmUNCgk+PiBkZSBJL08gZXN0ZSBkZWxvYyBkZSBuZWdsaWphdCBzaSBhciBh anV0YSBkZXN0dWwgZGUgbXVsdCBsYQ0KCT4+IGltYnVuYXRhdGlyZWEgc2NhbGFiaWxpdGF0aWkg KHNhdSwgY3UgYWx0ZSBjdXZpbnRlLCBjZSBtYSBzdXBhcmEgcGUNCgk+PiBtaW5lIGUgY2EgdHJl YnVpZSBzYSByZWludmVudGFtIHJvYXRhKS4NCgk+Pg0KCT4NCgk+IEN1IGNlIHRlIGFqdXRhIG1h IHJvZyBsYSBzY2FsYWJpbGl0YXRlYSBzaXN0ZW11bHVpIGZhcHR1bCBjYSBhaSAxLCAyDQoJPiBz YXUgIDEwDQoJPiB0aHJlYWQtdXJpIGluIG1vbWVudHVsIGluIGNhcmUgdGhyZWFkLXVyaWxlIHN0 YXUgc2kgYXN0ZWFwdGEgY29tcGxldGFyZWENCgk+IGEgc2EgemljZW0gMTAgb3BlcmF0aWkgZGUg SS9PPw0KCT4NCgk+IE9QPiBFIHNpbXBsdSwgZGFjYSBhaSBudW1hcnVsIGRlIHRocmVhZHVyaSBs aW1pdGF0IGxhIDEwIHNpIHRvYXRlIDEwDQoJPiBhc3RlYXB0YSBwZSBJL08sIGFsIDExLWxlYSBj bGllbnQgdmEgcHJpbWkgIlNlcnZlciBUb28gQnVzeSIuIERhY2EgYWkNCgkNCglUaHJlYWR1bCB0 cmVidWllIHNhIHBvYXRhIHByaW1pIGNlcmVyaSBub2kgYXRhdCB0aW1wIGNhdCBhc3RlYXB0YQ0K CXJlenVsdGF0dWwgZGUgbGENCgljZWxlbGF0ZSBjZXJlcmkuLi4gRGVjaSwgc3Vwcml6YSwgYWwg MTEtbGVhIGNsaWVudCBudSB2YSBwcmltaSAic2VydmVyIHRvbw0KCWJ1c3kiLA0KCWNpICJpIGFt IHJlYWR5IHRvIHJvY2siLg0KDQoJT1A+IFZhIHByaW1pIHVuICdyZWFkeSB0byByb2NrJyBkdXBh IGNhcmUgdmEgYXN0ZXB0YSBjYSBwcm9jZXNhcmVhIHNhIHNlIGludGFtcGxlIGVmZWN0aXYuIERh Y2EgaW5zYSBhciBmaSBhbmFsaXphdCB1biBwaWMgc2kgYXIgZmkgZGVjaXMgY2EgZSBtYWkgYmlu ZSBzYSBwb3JuZWFzY2EgdW4gbm91IHRocmVhZCwgcHJvY2VzYXJlYSBhciBmaSBwdXR1dCBkZWN1 cmdlIG1haSByYXBpZCwgZXhwbG9hdGFuZCBsYSBtYXhpbSBzaSBwcm9jZXNvcnVsIHNpIGRpc2N1 bDsgZGFjYSBhciBmaSBkZWNpcyBjYSBudSBlICBuZXZvaWUgZGUgaW5jYSB1biB0aHJlYWQsIGFy IGZpIGF2dXQgbG9jIGNlbGFsYWx0IHNjZW5hcml1LiBTaWd1ciwgaW50cnVjYXQgYXBsaWNhdGlh IGFzdGEgbnUgZmFjZSBjaW5lIHN0aWUgY2UgcHJvY2VzYXJlLCBwcm9iYWJpbCBjYSBudSBhcmUg Y2luZSBzdGllIGNlIGltcG9ydGFudGE7IG0tYW0gZ2FuZGl0IGluc2EgY2EsIGRhY2EgZGluIG1v bWVudCBjZSBhY2VsYXNpIGx1Y3J1IHNlIHBvYXRlIGZhY2UgaW4gbWFpIG11bHRlIG1vZHVyaSwg bnUgYXIgZmkgcmF1IHNhIGFuYWxpemFtIHNpIGFsdGUgYXNwZWN0ZSAocGVyZm9ybWFudGEsIHNj YWxhYmlsaXRhdGUsIGluICBhY2VzdCBjYXopIGNhbmQgZGVjaWRlbSBzYSBmb2xvc2ltIG8gYWJv cmRhcmUgc2F1IGFsdGEuDQoJDQoJPiBudW1hciBuZWxpbWl0YXQgZGUgdGhyZWFkdXJpICh0dW5h dCBkaW5hbWljIGRlIHNpc3RlbSwgaW4gZnVuY3RpZSBkZQ0KCT4gaW5jYXJjYXJlYSBkZSAgcGUg cHJvY2Vzb2FyZSwgc3RhdGlzdGljYSBkZSBDb250ZXh0IFN3aXRjaGVzLCBzaSB0b3QgY2UNCgk+ IG1haSBmYWNlIHVuIHNpc3RlbSAgZGUgb3BlcmFyZSBkZWNlbnQgaW50ZXJuKSwgbWFpIHRyZWJ1 aWUgc2EgbGltaXRlemkNCgk+IGRvYXIgbHVuZ2ltZWEgY296aWkgZGUNCgk+IHJlcXVlc3R1cmkg bmVwcm9jZXNhdGUgaW5jYSAocGVuZGluZykgLSBjYXJlIHBvYXRlIGZpIGRlIG9yZGludWwgbWlp bG9yDQoJPiBzYXUgIHplY2lsb3IgZGUgbWlpLiBFdSB6aWMgY2EgYWp1dGEgZGFjYSBpbmNlcmNp IHNhIHZpbnppIG8gYXBsaWNhdGllDQoJPiBzZXJ2ZXIsDQoJPiBkYXIgbWEgcm9nLCBhbSBpbXBy ZXNpYSBjYSBhaWNpIGludmF0YW0sIG51IGdhbmRpbSA6KQ0KCT4NCgkNCglNaWUgbnUgbWkgc2Ug cGFyZSBuaWNpIGNhIGdhbmRlc3RpLCBuaWNpIGNhIHZyZWkgc2EgaW52ZXRpIGNldmEuDQoNCglP UD4gTWllIGV4cHJpbWFyZWEgYXN0YSBtaSBzZSBwYXJlIGNhbSByYWRpY2FsYSBzaSBldSB1bnVs IGFzIGZpIGV2aXRhdC1vLCBtYWNhciBkaW4gcG9saXRldGUgZGFjYSBudSBkaW4gYWx0ZSBtb3Rp dmUuIERhY2Egc3VnZXN0aWEgbWVhIGEgZm9zdCBkZXBsYXNhdGEsIG1hIGFzdGVwdGFtIGxhIG8g ZXhwbGljYXRpZSBkZSBnZW51bCAiVWl0ZSwgcGVudHJ1IGFwbGljYXRpYSBhc3RhIGUgbWFpIGJp bmUgc2EgZmFjaSBjdW0gZSBpbiBjZXJpbnRhIHBlbnRydSBjYS4uLiIsIG51IHVuIHJhc3B1bnMg Y2xpc2V1IGRlIHRpcHVsICJDZSBwYXJ0ZSBkaW4gPHRyZWJ1aWU+IG51IGludGVsZWdpIi4uLg0K CQ0KCXRhdmkNCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KCXNvIG1haWxpbmcgbGlzdA0KCXNvQGF0bGFudGlzLmNzLnB1Yi5ybw0KCWh0dHA6Ly9h dGxhbnRpcy5jcy5wdWIucm8vY2dpLWJpbi9tYWlsbWFuL2xpc3RpbmZvL3NvDQoJDQoNCg== ------_=_NextPart_001_01C3B977.8C981FD4 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhUIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA4gQAAAAAAADmAAENgAQAAgAAAAIAAgABBYAD AA4AAADTBwwAAwAKAB0AFAADACcBASCAAwAOAAAA0wcMAAMACgAdABQAAwAnAQEJgAEAIQAAADdG MUREREE4MEZBN0QzNEE4ODNBOTU0QzhCNTczODcyAFAHAQOQBgDsFgAAOAAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAADAAAABSAEUAOgAgAFsAcwBvAF0A IABlAGcAYQBsACAAaQBuAGMAYQByAGMAYQB0AGUAAABAADkA1B+YjHe5wwEfAD0AAQAAAAoAAABS AEUAOgAgAAAAAAACAUcAAQAAACoAAABjPXVzO2E9IDtwPU1TTGFiO2w9U0VSVkVSLTAzMTIwMzA4 MjkyMFotMQAAAB8ASQABAAAAMAAAAFIAZQA6ACAAWwBzAG8AXQAgAGUAZwBhAGwAIABpAG4AYwBh AHIAYwBhAHQAZQAAAEAATgAAhJQTI7nDAR8AWgABAAAAIgAAAE8AYwB0AGEAdgBpAGEAbgAgAFAA dQByAGQAaQBsAGEAAAAAAAIBWwABAAAAPQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE9jdGF2 aWFuIFB1cmRpbGEAU01UUAB0YXZpQGNzLnB1Yi5ybwAAAAACAVwAAQAAABQAAABTTVRQOlRBVklA Q1MuUFVCLlJPAB8AXQABAAAAIgAAAE8AYwB0AGEAdgBpAGEAbgAgAFAAdQByAGQAaQBsAGEAAAAA AAIBXgABAAAAPQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE9jdGF2aWFuIFB1cmRpbGEAU01U UAB0YXZpQGNzLnB1Yi5ybwAAAAACAV8AAQAAABQAAABTTVRQOlRBVklAQ1MuUFVCLlJPAB8AZgAB AAAACgAAAFMATQBUAFAAAAAAAB8AZwABAAAAHgAAAHQAYQB2AGkAQABjAHMALgBwAHUAYgAuAHIA bwAAAAAAHwBoAAEAAAAKAAAAUwBNAFQAUAAAAAAAHwBpAAEAAAAeAAAAdABhAHYAaQBAAGMAcwAu AHAAdQBiAC4AcgBvAAAAAAAfAHAAAQAAACgAAABbAHMAbwBdACAAZQBnAGEAbAAgAGkAbgBjAGEA cgBjAGEAdABlAAAAAgFxAAEAAAAbAAAAAcO5I1Npu7gfj6BtRlulBLJaC94AfQAUwDFbAB8AdAAB AAAALAAAAHMAbwBAAGEAdABsAGEAbgB0AGkAcwAuAGMAcwAuAHAAdQBiAC4AcgBvAAAAHwAaDAEA AAAcAAAATwB2AGkAZABpAHUAIABQAGwAYQB0AG8AbgAAAB8AHQ4BAAAAKAAAAFsAcwBvAF0AIABl AGcAYQBsACAAaQBuAGMAYQByAGMAYQB0AGUAAAACAQkQAQAAAP8OAAD7DgAA4TEAAExaRnXnqYwQ AwAKAHJjcGcxMjWCMgNDaHRtbDEDMD8BAwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYI VQeyEdUOUQMB3RDXMgYABsMR1TMERhDZbxLrEeMI7wn3OxjPDjA1OxHSDGBjAFALCQFkMzaTEWAL pTQgEAIqXA6yvQGQZxTwCqMR4x3oNBTwADwhRE9DVFlQAEUgSFRNTCBQAFVCTElDICItIC8vVzND IYBEVCJEIJQzLjIhgEVOnCI+Hu0ejyPBMTgf8G8goiMPJB8mkDMdgCVwRXxBRCXNDvEm7ylvJPQ2 QQ7wPE1FVEEHsEExLGA9IkcJ8ASQYXRFBbAiEtBPTlQi0FQTLPAF4UV4EPFuZ2U9BlJ2EzEvQQCQ AiAgNhAuMC42HXA5LjEnIv4qzyUDNzcf8FRJKFRMRSXONA7wUmUAOiBbc29dIGVqZwdAIAuAYwrA NcB06mUkbjUf8C8zTzF/JkVfNJE3UChPJp87JDURYDwAQk9EWSBkaXL6PTtAcjqQOwMAIQMwPaGc ZG8A4D2hCrFccRiw/z2hEPADMD4FEWA6uxzxO7+IZzk2H/BESVY92WcAAEAXOtk2NENPQG84wR2A Jm5ic3ACgD34/CdhAUBEDztRAcA95wqi9z3nCnEkfDAoESHgQxtLOB9An0GvQrMhECAwS1FVBk8t 8D1WIHN0eWwCZS4xQVJHSU4tGFJJRyCgNOAwcHj/IvE9+AqxEAI/BT+jP2E///9PHx8bEWBY8E// Qv9JD0UfW1YXPoBpHNIkfDQlUUbTLdFSMGl6UoAyWnsL4tVV+S1h8k8FEGcLgDVx6k0HkHM7YGVh 815dLBDtPPFSPdsLgGUKgVYfRzarPQBae2JV+UYDYTpZPI0f4S9nuk4JIE9jAZD2dgcwA6BQCHA9 YAtgHZzvHYBXn0djWQFbAMADEC1wAjpsYkBjcy5wdfxiLgNgNTBjr2S/Zc9m339n73P0BmACMGmf aq9rt1dFCYAgDiAvMy8B0DD6M3ohOh1xLMBxT3Jfc2/3dH91j331VHAwd194b2vG721fbm9vdDUQ QC1gC2ACMP0EAC5wp3tffG99f36Pf5/5ilVDY4E/gk+DX4hPiV/vim+Lf3YecOBqBZB3P46f/2uo NMyD74T/b3Q1p5BPkV9fkm+dP55Pn18k1jVaES//X4KXr0lPSl9Lb0x/pK9Wj++a71ivXDUf8FBT 311ZXM+vXd9e71//YQ1PA6BUClB0LCAU8EQFkLYAepM3zjo80HrwEWArMHqBtfB2T2yAPWB1me+r /29lUPsLYC1wbqAPoR+iL0bsO0A1SAk8vXhvt9MLUEBt7w3gA2A1EAGALQtgcPBw1NW+H2e/Oj5r mXcDYDYQ/5Zsu++8/5//xn/Hj8Kfw6+/yy/JP8pPy1/Mb2uoQy7wp7g/uU+GBWVtAwBmDeD7LWAI kCCG4FIwLvAKsS7wpTXAINeTdXaGwXUDICIiPbBlYnUIkCI//84Pzx/QL9E/0k/cP9pP21933G/d f2u4UOIP4x9rxk6vuB/Uz4XnhuB1tfBkCsGrh6BjACAAwCA1YG4BAM0E8C7roLYgdWjrod8P/+Af 4S/k/+YP7w/tH+4v8c/78t/z7UPXkgqxNhA9UQOg+djXIG7nf+iPb1aHoAuA/zYQUnBicNlto++q HKa/p8X/rs/0X6ZEN0Gukar/+q+tH/+uL7DPsd+y77P/tQjkv/BP/Wu3UGJQb+DsH/W/9s8QT/8R XxJvDV8ObxYPFx8PCy7wplf4kD7Ad3O18GP8YPXXcHWG4G618PmfBQ+GBf/A8C2A2JETTxRfFW8Z Dxof/yKvI7/EWi+wUkDWYNig2SCzPVAu8G9wLUH38nTXEFpo16BhehAfgG8h4Wf718BpcGJigSmA 2EAc3x3v7/umKQKG4NcwYS+wNbDBYP8iAiAPIR8iLyXPJt8x3zLv42uoKMFJL0+ZkCgxKLGubD7Q KLIxEGcJEGoq8fcoENfx1/BqHIBtPyxPb1b/62HYkijBKGEpgG0gLv8wD/8xHzS/Nc9AH0EvxFoP 4NkQfyrh1tEpwVIw19DB0W0QaftF4tcwKOrQ6kErIZnA+FH/Oc8637pU2EH8MhwS6vIfYf/qgDmg KQA9Xz5vP39DH0Qv/07/UA/EWsEwTlCZkNfC+NWX6sLXoPiQdncRYW1IL+9JP29lwWBF0SkQP00/ Tk//Ue9S/1wPXR9eL1mvWr9g7/9fb2B/YY9in2OvZL9lz9Nj/yswS0H4UTlk6wHBYCpwwdA/RltG MVZvV3+GBSgoZmHvKXDYodfSRzAxtfFnD2gfP2kvaj9rTyfER3B2b25ihHNwv0lcJ2EwGsn/qQBz b3R/dY92n3evGyMppHwtdQ/Q/CFvH3AvSkVt/yqgVgHYofiRnJHXAYH3/HD/S5AEkCswOQI3oXJh bwAqkf3BAGUEkCnBfE99X35vf3/vgI8bI0ZBbwB61rDWYIK//4PPSkWpACjkLiI3JNlvie//iv+M D40flZ+Tr5S/lc+W3+/kD5vPnN8GMUUK0YhR6kP3csT5YOsAcjyEjz+QT7pU/ymkglIJEMEwReFt 8pGxOQH/uuBu0XwfmV+ab54/n0+OB7+HtikAN0K18G5QtrAxwcD9RjFjCRBWAaKfo69KRdhg59dw D9FHMCJTKRBV8OqQAlQqICBCdXN5Iv/rwaGEp1+ob6l/s/+1D7YZ/lSlNDyQVQkfgEXRsbWvH9+w L0pVKRApEKHRby5BpgL/6iCIUNfBKYCHprbPt9+17P3XoHo88dbQPIQ9P8FPtc7/HDH8YKbyvkTr orvPvN9KVHBEZWNpHMBLoQ/Qev5hre8pgPlhsZjXULJTptC+b8RfxW+17NkQswEszn//z4/GfbIB LkGPH8l/WGcp0eZ5psFtsWNrsyD8z/3f//7v//8BD7Y/Ay8EPwVPBl//B28IfwmPCp8Lrwy/qv+d LaZWsaZFsCAn1+snoWD/S7GF9LGRh6KH8tVv4R9KVf/ETHoPex6xwDgQN5CIorrC383Q/CLVMIhh N4BmyxBHEN52szX4kFWB7/FmLkEq4O/lIMuwKYDsYXCO4Djy7u/f7/9KVPc0PEDLIHNUwktS90cw KsG6tXK14C5gVNHsYf++sCswKaQcwPRp9zQccTmAz/i/+c871ysgcmf8NEvg8/hQ/nFleIhgWPIb wG3y/W2QeA/gOPL0ZB+QcpE5AeZkKCArIGw7oWX3QwAf/wEvAjf71M0BTCzyX3sfteB+dr7AN8KC gf2E/ib3NXb//+E4AhwxblE9AQdPCF8fBRdLQCrgu3B1szBTaWf/glAcwErhojC/k4hgjuBHAf/u QwozclBLQcsg/LJHEMfC3/RYHM8Rn0o29GFibnIKFX8pMhY7oQEfkfeQ4KAGcG36LdUxZwQxRuD2 1FTQoVX/BhCCrxivhMxLMhXxxDA5Af8ogC6gh1EpUabjFeOF0fxS+zziPMFvpXIXkBrz91JL4P+H Ue7PH8/6x/ekBONH4y5g1y3g9jBtECgt4WYFkG2Q/1YRy0FuShQSCp8Lr3tbFfHzN6BUwXopVMEE QSYPJx//CWg8QAThJeAqUDgAoPGR0H0pgGIFkKFwhiFHYUfSYf9ZT9Lftd81DzYfNy/pj+qf/w1S ogINcaXGon8w36SfRzH/coBFwR6C1TD4YT6BcaQUEv9yQEWw9jEN0jfvOP86Dzsf9zwv64MOInKG Ah5xCo8tD/97TD6/P88Z1RbmWPAXcochz5IwFoEeYm0QQ29WEAPAyb8gU3dusGNo9KDLQf+msiGi RE9FX0ZvR39Ij+uD//xSFePsYU2vTr9xSlavS8//e1s+gZHjhiH7oa7SFDGSAPxuKReQ/FK6WaXD w2Czv/9Ur1W/Vs9X3191ULFZ/1sPszIFchBuZzNwrnJvjtD/+4Ji/2QPZR9mL2c/64OGIPxxdS8R glJukPRlKeEOI+8qER1ha4AvgC2F9CMEaO//af8yFPtzkdAz8IXQokE+IP8akAWQbH9tj26fb69w v+uD/zRRfA9d/y4r5xDLIHjRkmI7eKGzMEUlEI7R+/Jhav//wB5xoYJ1T3ZfMhQOIZIA+9TR9RF2 Q3CO0DOSFNVsb/96D3sffC99P35FskPRz4lff4pvi3+Mj191hSH8UNhhZ//L0dVAoQHuAObwg/+F D/Do/6Gx1NFDcLGQ9ZEk4x1D1UD8OimOb49/kI+Rn5KvnJ/fmq+bv59foG+hfU26oSUB97HxItLt 8m6YQoPvlm8x5+8dQi8RJNKmlXbuAIbzmIH+Zb9AEAGxkNjP2d/a79v//90Poc/fL+A/4U/iX+Nv 5H//5Y/mn+ev6L+db+repWIDwf/Ncf8EFXKl2f2A1UADUB6Q+ysCBdJlJRBDsMPRpw+0L5/65fvg 92ENkCtyLW9hYv/t4R6D/RArYatQDdEGoiUB7x6SKUMhUPZBZfZ1y2AC4P8WgQSB/yHCX8Nv+uUz ES8h/z6AFNApkAQRYWLuVtVABHE/2FADwof0DeIC4MISIlX/YqH+gSGBIqEUyMm/ys/Edv/usfw8 FeGmsT2Q/CFDcYax1/Vy0Ab9gC7WwCIk4+xh/wNQgABDsPvhuDCN8CUQ0S+30j8yFg6Qaf+wz4FD phPfxtIerr0StPC9eTyxKGHF/9xvvV89CNhv2X+GJyng9dD9a5Ai1sGib6N/oY/lr+a//+fJs7CH QOh/6Y/nn+vv7P/97glf8b/yz/Oa7r/vz+3cvwWA4i/jPyDm/GDtsWdiYe9coPSv9b/2zkBRMARw 5MCZCfAuY/6w17BiLhpAz/sf/C/t35cLPEH4tLVgEQ6xZj0i4MB0cDpELy/+T28vY2uQLe3UUS/6 UiqBL/rSQ3AqUJovUKAiumwNwGxktIIGZgjAHbF0e0hZUMBFUkxJTkvPkARvZwV/Bo8HkX19uxEI wHKCc7TwXGNmMVx4cf8ByApfC28Mf1CgrX+uiRNa9bMbObKiQbL9AD8BTxQP/65/r4+wn7Gvsr+1 ErmBrQUFuJwwtoEvQkxPQ8BLUVVPVEWtXx2vF7PfJI+0pzUgMkJPRC5ZHy4mP7UCN6zhSFQUTUwX 4H0rAAAfADUQAQAAAIoAAAA8ADMANgBDADgAMQA2ADQAQQBFADAAQwA2AEMAQQA0ADkAOAA3AEMA MwBFAEMAOAA4AEEAMQBCAEIANAAxADYAQQAwADEANAA3ADEANwBAAHMAZQByAHYAZQByAC4AbQBp AGMAcgBvAHMAbwBmAHQALQBsAGEAYgAuAHAAdQBiAC4AcgBvAD4AAAAAAB8ARxABAAAAHgAAAG0A ZQBzAHMAYQBnAGUALwByAGYAYwA4ADIAMgAAAAAACwDyEAEAAAAfAPMQAQAAADwAAABSAEUAJQAz AEEAIABbAHMAbwBdACAAZQBnAGEAbAAgAGkAbgBjAGEAcgBjAGEAdABlAC4ARQBNAEwAAAALAPYQ AAAAAEAABzBQOixUdrnDAUAACDCWC6SMd7nDAQMA3j/p/QAAAwDxPwkEAAAfAPg/AQAAABwAAABP AHYAaQBkAGkAdQAgAFAAbABhAHQAbwBuAAAAAgH5PwEAAABdAAAAAAAAANynQMjAQhAatLkIACsv 4YIBAAAAAAAAAC9PPU1TTEFCL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQ SUVOVFMvQ049T1ZJRElVUEwAAAAAHwD6PwEAAAAqAAAAUwB5AHMAdABlAG0AIABBAGQAbQBpAG4A aQBzAHQAcgBhAHQAbwByAAAAAAACAfs/AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAA AAAALgAAAAMA/T/kBAAAAwAZQAAAAAADABpAAAAAAAMAHUAAAAAAAwAeQAAAAAAfADBAAQAAABIA AABPAFYASQBEAEkAVQBQAEwAAAAAAB8AMUABAAAAEgAAAE8AVgBJAEQASQBVAFAATAAAAAAAHwAy QAEAAAAeAAAAdABhAHYAaQBAAGMAcwAuAHAAdQBiAC4AcgBvAAAAAAAfADNAAQAAAB4AAAB0AGEA dgBpAEAAYwBzAC4AcAB1AGIALgByAG8AAAAAAB8AOEABAAAAEgAAAE8AVgBJAEQASQBVAFAATAAA AAAAHwA5QAEAAAAEAAAALgAAAAsAKQAAAAAACwAjAAAAAAADAAYQetRk0AMABxDeCAAAAwAQEAAA AAADABEQAAAAAB4ACBABAAAAZQAAAC0tLS0tT1JJR0lOQUxNRVNTQUdFLS0tLS1GUk9NOk9DVEFW SUFOUFVSRElMQU1BSUxUTzpUQVZJQENTUFVCUk9TRU5UOldFRDEyLzMvMjAwMzEyOjI0QU1UTzpT T0BBVExBTlQAAAAAAgF/AAEAAABFAAAAPDM2QzgxNjRBRTBDNkNBNDk4N0MzRUM4OEExQkI0MTZB MDE0NzE3QHNlcnZlci5taWNyb3NvZnQtbGFiLnB1Yi5ybz4AAAAAtDw= ------_=_NextPart_001_01C3B977.8C981FD4-- From so@atlantis.cs.pub.ro Wed Dec 3 12:27:10 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Wed, 03 Dec 2003 14:27:10 +0200 Subject: [so] egal incarcate In-Reply-To: <36C8164AE0C6CA4987C3EC88A1BB416A014717@server.microsoft-lab.pub.ro> References: <36C8164AE0C6CA4987C3EC88A1BB416A014717@server.microsoft-lab.pub.ro> Message-ID: ------------o3NZmg3w1L6b6j9DIGn5Zu Content-Type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 8bit On Wed, 3 Dec 2003 10:29:20 +0200, Ovidiu Platon wrote: > > OP> Va primi un 'ready to rock' dupa care va astepta ca procesarea sa > se intample efectiv. Daca insa ar fi analizat un pic si ar fi decis ca e > mai bine sa porneasca un nou thread, procesarea ar fi putut decurge mai > rapid, exploatand la maxim si procesorul si discul; Dupa ce thread-ul primeste datele, adica asteapta la I/O, el le va trimite prin socket, deci face alta operatie de I/O. Intercalat cu aceste operatii mai executa 10-20 de instructiuni masina in care mai faci mici chestii administrative, ca de exemplu scoate cererea din coada. Aparent avem aici o latenta de 10-20 instr care pentru un numar mare de cereri creste liniar, astfel incat avem o latenta de N*(10-20) instructiuni, corect? Nope. Pentru ca, latenta de 10-20 instr se compenseaza prin faptul ca in timp ce asteptam la I/O putem executa celelalte 10-20 instr. Asa ca lucrurile stau destul de bine atunci cand se foloseste un singur thread, pentru valori ale lui N relativ mari. Pentru exemplificare vedeti programul atasat (si tineti cont de faptul ca printf face pana la urma un apel de sistem, deci e relativ costisitor). > daca ar fi decis ca nu e nevoie de inca un thread, ar fi avut loc > celalalt scenariu. Sigur, Daca se folosesc mai multe thread-uri, apare o latenta la comutarea thread-urilor. Astfel incat nu are sens sa folositi mai multe thread-uri decat daca sunt prezente in sistem mai multe procesoare. Pentru asta exista parametri pentru server. > > OP> Mie exprimarea asta mi se pare cam radicala si eu unul as fi > evitat-o, macar din politete daca nu din alte motive. Daca sugestia mea > a fost deplasata, ma asteptam la o explicatie de genul "Uite, pentru > aplicatia asta e mai bine sa faci cum e in cerinta pentru ca...", nu un > raspuns cliseu de tipul "Ce parte din nu intelegi"... > Daca mailul l-ar fi scris altcineva, asa as fi procedat. La genul de mailuri pe care le trimiti insa, am considerat ca are sens sa imi exprim clar parerea fata de atitudini de genul "tampenia aia de MinGW", "am impresia ca aici invatam, nu gandim" care sunt afirmatii gratuite ce nu au nici o sustinere. In plus, afirmatii de genu asta nu au ce cauta pe lista, si daca este cazul o sa renunt la compania celor ce in continuare, in mod repetat nu respecta regulile. tavi ------------o3NZmg3w1L6b6j9DIGn5Zu Content-Disposition: attachment; filename=aio.c Content-Type: application/octet-stream; name=aio.c Content-Transfer-Encoding: 8bit #include #include int main(int argc, char **argv) { int fd=open(argv[1], O_RDONLY), i, tmp; char buff[64000]; struct aiocb aio = { aio_fildes: fd, aio_offset:0, aio_buf:buff, aio_nbytes:64000, aio_reqprio:0, aio_sigevent: { sigev_notify:SIGEV_NONE }, aio_lio_opcode: LIO_READ, }; aio_read(&aio); for(i=0; i<=1000000; i++) { printf("\r %d %d", i, tmp=aio_return(&aio)); if (tmp) { printf("\n"); return 0; } } return 0; } ------------o3NZmg3w1L6b6j9DIGn5Zu-- From so@atlantis.cs.pub.ro Thu Dec 4 15:56:30 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Thu, 04 Dec 2003 17:56:30 +0200 Subject: [so] probleme lista Message-ID: Dupa cum probabil ati constatat, lista de mail a avut probleme incepand cu ieri de la pranz. Aceste probleme s-au rezolvat acum. Toate mailurile trimise in perioada cu probleme au fost pierdute. tavi From so@atlantis.cs.pub.ro Thu Dec 4 15:58:50 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Thu, 4 Dec 2003 17:58:50 +0200 Subject: [so] tema4 Message-ID: <001201c3ba7f$82e03310$390c6150@ioana> This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C3BA90.4580C5F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Daca un client trimite o cerere de scriere intr-un fisier care nu = exista, acel fisier este creat si in el va fi scris ce vrea clientul, = sau se da eroare ca fisierul nu exista? Clientului nu ar trebui sa i se dea adresa serverului? ------=_NextPart_000_000F_01C3BA90.4580C5F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Daca un client = trimite o cerere=20 de scriere intr-un fisier care nu exista, acel fisier este creat si in = el va fi=20 scris ce vrea clientul, sau se da eroare ca fisierul nu exista?

Clientului nu ar = trebui sa i se=20 dea adresa serverului?

------=_NextPart_000_000F_01C3BA90.4580C5F0-- From so@atlantis.cs.pub.ro Thu Dec 4 16:03:38 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Thu, 04 Dec 2003 18:03:38 +0200 Subject: [so] tema4 In-Reply-To: <001201c3ba7f$82e03310$390c6150@ioana> References: <001201c3ba7f$82e03310$390c6150@ioana> Message-ID: On Thu, 4 Dec 2003 17:58:50 +0200, Ioana Cutcutache wrote: > Daca un client trimite o cerere de scriere intr-un fisier care nu > exista, acel fisier este creat si in el va fi scris ce vrea clientul, > sau se da eroare ca fisierul nu exista? Adoptati ce politica doriti. Specificati politica aleasa in README. > Clientului nu ar trebui sa i se dea adresa serverului? Ba da. O sa corectez in enunt. tavi From so@atlantis.cs.pub.ro Thu Dec 4 19:30:14 2003 From: so@atlantis.cs.pub.ro (Dorin Moise) Date: Thu, 04 Dec 2003 21:30:14 +0200 Subject: [so] aiocb.aio_sigevent Message-ID: <200312041930.hB4JUE9Y006216@k.k.ro> Cum ar trebui sa afle un "signal handler" ce operatie AIO s-a incheiat?!? Spre exemplu, unul din cele X threaduri incepe o operatie asincrona - dupa ce mai intai a deschis fisierul pe care "opereaza" - si specifica un semnal care sa fie "declansat" cand operatia se incheie. Intrebarea e : cine va inchide fisierul?!? Thanks. ----------------------------------------- .dorin moise Sentimente.ro - www.sentimente.ro Peste 50.000 de prieteni te asteapta! From so@atlantis.cs.pub.ro Thu Dec 4 20:43:01 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Thu, 4 Dec 2003 22:43:01 +0200 Subject: [so] aiocb.aio_sigevent References: <200312041930.hB4JUE9Y006216@k.k.ro> Message-ID: <001401c3baa7$368645e0$020c6150@ioana> Daca te referi la cum determini care din operatiile asincrone s-a terminat (daca ai pornit mai multe) folosesti functia aio_error si verifici fiecare structura aiocb asociata unei operatii asincrone pornite. Aio_error iti intoarce EINPROGRESS daca operatia nu s-a terminat inca. In felul asta vezi care s-au terminat si faci cleanup-ul (inchidere fisier) si ce mai ai nevoie sa faci. ----- Original Message ----- From: "Dorin Moise" To: Sent: Thursday, December 04, 2003 9:30 PM Subject: [so] aiocb.aio_sigevent > > > Cum ar trebui sa afle un "signal handler" ce operatie AIO s-a incheiat?!? > > Spre exemplu, unul din cele X threaduri incepe o operatie asincrona - dupa > ce mai intai a deschis fisierul pe care "opereaza" - si specifica un semnal > care sa fie "declansat" cand operatia se incheie. Intrebarea e : cine va > inchide fisierul?!? > Thanks. > ----------------------------------------- > .dorin moise > > > > > > > Sentimente.ro - www.sentimente.ro > Peste 50.000 de prieteni te asteapta! > > > > > _______________________________________________ > so mailing list > so@atlantis.cs.pub.ro > http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so > From so@atlantis.cs.pub.ro Fri Dec 5 08:46:51 2003 From: so@atlantis.cs.pub.ro (Ovidiu Platon) Date: Fri, 5 Dec 2003 10:46:51 +0200 Subject: [so] egal incarcate Message-ID: <36C8164AE0C6CA4987C3EC88A1BB416A014719@server.microsoft-lab.pub.ro> This is a multi-part message in MIME format. ------_=_NextPart_001_01C3BB0C.53F83344 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXVsdHVtZXNjIHB0IGxhbXVyaXJpLiBUb2F0YSBpZGVlYSBlcmEgY2EgZGVjYXQgc2EgdHVuYW0g ZGUgbWFuYSBudW1hcnVsIGRlIHRocmVhZHVyaSwgbWFpIGJpbmUgbGFzYW0gc2lzdGVtdWwgc2Eg ZmFjYSBhc3RhLCBkYXIsIGluIGZpbmUsIGVyYSBkb2FyIG8gc3VnZXN0aWUuLi4NCkluIGNlZWEg Y2UgcHJpbWVzdGUgYWZpcm1hdGlpbGUsIHN1bnQgZGUgYWNvcmQgY2EgbGltYmFqdWwgYSBmb3N0 IHB1dGluIGRlcGxhc2F0LiBJbiBsZWdhdHVyYSBjdSBncmF0dWl0YXRlYSBsb3IsIGluc2EsIGFt IGR1YmlpLg0KIA0KTXVsdHVtZXNjLA0KT3ZpZGl1DQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLSANCglGcm9tOiBPY3RhdmlhbiBQdXJkaWxhIFttYWlsdG86dGF2aUBjcy5wdWIucm9dIA0K CVNlbnQ6IFdlZCAxMi8zLzIwMDMgMjoyNyBQTSANCglUbzogc29AYXRsYW50aXMuY3MucHViLnJv IA0KCUNjOiANCglTdWJqZWN0OiBSZTogW3NvXSBlZ2FsIGluY2FyY2F0ZQ0KCQ0KCQ0KDQoNCglP biBXZWQsIDMgRGVjIDIwMDMgMTA6Mjk6MjAgKzAyMDAsIE92aWRpdSBQbGF0b24NCgk8b3ZpZGl1 cGxAbWljcm9zb2Z0LWxhYi5wdWIucm8+IHdyb3RlOg0KCQ0KCT4NCgk+ICAgICAgIE9QPiBWYSBw cmltaSB1biAncmVhZHkgdG8gcm9jaycgZHVwYSBjYXJlIHZhIGFzdGVwdGEgY2EgcHJvY2VzYXJl YSBzYQ0KCT4gc2UgaW50YW1wbGUgZWZlY3Rpdi4gRGFjYSBpbnNhIGFyIGZpIGFuYWxpemF0IHVu IHBpYyBzaSBhciBmaSBkZWNpcyBjYSBlDQoJPiBtYWkgYmluZSBzYSBwb3JuZWFzY2EgdW4gbm91 IHRocmVhZCwgcHJvY2VzYXJlYSBhciBmaSBwdXR1dCBkZWN1cmdlIG1haQ0KCT4gcmFwaWQsIGV4 cGxvYXRhbmQgbGEgbWF4aW0gc2kgcHJvY2Vzb3J1bCBzaSBkaXNjdWw7DQoJDQoJRHVwYSBjZSB0 aHJlYWQtdWwgcHJpbWVzdGUgZGF0ZWxlLCBhZGljYSBhc3RlYXB0YSBsYSBJL08sIGVsIGxlIHZh IHRyaW1pdGUNCglwcmluIHNvY2tldCwgZGVjaQ0KCWZhY2UgYWx0YSBvcGVyYXRpZSBkZSBJL08u IEludGVyY2FsYXQgY3UgYWNlc3RlIG9wZXJhdGlpIG1haSBleGVjdXRhIDEwLTIwDQoJZGUgaW5z dHJ1Y3RpdW5pDQoJbWFzaW5hIGluIGNhcmUgbWFpIGZhY2kgbWljaSBjaGVzdGlpIGFkbWluaXN0 cmF0aXZlLCBjYSBkZSBleGVtcGx1IHNjb2F0ZQ0KCWNlcmVyZWEgZGluIGNvYWRhLg0KCQ0KCUFw YXJlbnQgYXZlbSBhaWNpIG8gbGF0ZW50YSBkZSAxMC0yMCBpbnN0ciBjYXJlIHBlbnRydSB1biBu dW1hciBtYXJlIGRlDQoJY2VyZXJpIGNyZXN0ZSBsaW5pYXIsIGFzdGZlbA0KCWluY2F0IGF2ZW0g byBsYXRlbnRhIGRlIE4qKDEwLTIwKSBpbnN0cnVjdGl1bmksIGNvcmVjdD8gTm9wZS4gUGVudHJ1 IGNhLA0KCWxhdGVudGEgZGUgMTAtMjAgaW5zdHIgc2UNCgljb21wZW5zZWF6YSAgcHJpbiBmYXB0 dWwgY2EgaW4gdGltcCBjZSBhc3RlcHRhbSBsYSBJL08gcHV0ZW0gZXhlY3V0YQ0KCWNlbGVsYWx0 ZSAxMC0yMCBpbnN0ci4NCglBc2EgY2EgbHVjcnVyaWxlIHN0YXUgZGVzdHVsIGRlIGJpbmUgYXR1 bmNpIGNhbmQgc2UgZm9sb3Nlc3RlIHVuIHNpbmd1cg0KCXRocmVhZCwgcGVudHJ1IHZhbG9yaSBh bGUgbHVpIE4gcmVsYXRpdg0KCW1hcmkuIFBlbnRydSBleGVtcGxpZmljYXJlIHZlZGV0aSBwcm9n cmFtdWwgYXRhc2F0IChzaSB0aW5ldGkgY29udCBkZQ0KCWZhcHR1bCBjYSBwcmludGYgZmFjZSBw YW5hIGxhIHVybWENCgl1biBhcGVsIGRlIHNpc3RlbSwgZGVjaSBlIHJlbGF0aXYgY29zdGlzaXRv cikuDQoJDQoJPiBkYWNhIGFyIGZpIGRlY2lzIGNhICBudSBlICBuZXZvaWUgZGUgaW5jYSB1biB0 aHJlYWQsIGFyIGZpIGF2dXQgbG9jDQoJPiBjZWxhbGFsdCBzY2VuYXJpdS4gU2lndXIsDQoJDQoJ RGFjYSBzZSBmb2xvc2VzYyBtYWkgbXVsdGUgdGhyZWFkLXVyaSwgYXBhcmUgbyBsYXRlbnRhIGxh IGNvbXV0YXJlYQ0KCXRocmVhZC11cmlsb3IuIEFzdGZlbCBpbmNhdCBudQ0KCWFyZSBzZW5zIHNh IGZvbG9zaXRpIG1haSBtdWx0ZSB0aHJlYWQtdXJpIGRlY2F0IGRhY2Egc3VudCBwcmV6ZW50ZSBp bg0KCXNpc3RlbSBtYWkgbXVsdGUgcHJvY2Vzb2FyZS4gUGVudHJ1DQoJYXN0YSBleGlzdGEgcGFy YW1ldHJpIHBlbnRydSBzZXJ2ZXIuDQoJDQoJPg0KCT4gICAgICAgT1A+IE1pZSBleHByaW1hcmVh IGFzdGEgbWkgc2UgcGFyZSBjYW0gcmFkaWNhbGEgc2kgZXUgdW51bCBhcyBmaQ0KCT4gZXZpdGF0 LW8sIG1hY2FyIGRpbiBwb2xpdGV0ZSBkYWNhIG51IGRpbiBhbHRlIG1vdGl2ZS4gRGFjYSBzdWdl c3RpYSBtZWENCgk+IGEgZm9zdCBkZXBsYXNhdGEsIG1hIGFzdGVwdGFtIGxhIG8gZXhwbGljYXRp ZSBkZSBnZW51bCAiVWl0ZSwgcGVudHJ1DQoJPiBhcGxpY2F0aWEgYXN0YSBlIG1haSBiaW5lIHNh IGZhY2kgY3VtIGUgaW4gY2VyaW50YSBwZW50cnUgY2EuLi4iLCBudSB1bg0KCT4gcmFzcHVucyBj bGlzZXUgZGUgdGlwdWwgIkNlIHBhcnRlIGRpbiA8dHJlYnVpZT4gbnUgaW50ZWxlZ2kiLi4uDQoJ PiAgICAgIA0KCQ0KCURhY2EgbWFpbHVsIGwtYXIgZmkgc2NyaXMgYWx0Y2luZXZhLCBhc2EgYXMg ZmkgcHJvY2VkYXQuIExhIGdlbnVsIGRlDQoJbWFpbHVyaSBwZSBjYXJlDQoJbGUgdHJpbWl0aSBp bnNhLCBhbSBjb25zaWRlcmF0IGNhIGFyZSBzZW5zIHNhIGltaSBleHByaW0gY2xhciBwYXJlcmVh IGZhdGENCglkZSBhdGl0dWRpbmkNCglkZSBnZW51bCAidGFtcGVuaWEgYWlhIGRlIE1pbkdXIiwg ImFtIGltcHJlc2lhIGNhIGFpY2kgaW52YXRhbSwgbnUgZ2FuZGltIg0KCWNhcmUNCglzdW50IGFm aXJtYXRpaSBncmF0dWl0ZSBjZSBudSBhdSBuaWNpIG8gc3VzdGluZXJlLg0KCQ0KCUluIHBsdXMs IGFmaXJtYXRpaSBkZSBnZW51IGFzdGEgbnUgYXUgY2UgY2F1dGEgcGUgbGlzdGEsIHNpIGRhY2Eg ZXN0ZQ0KCWNhenVsIG8gc2EgcmVudW50IGxhDQoJY29tcGFuaWEgY2Vsb3IgY2UgaW4gY29udGlu dWFyZSwgaW4gbW9kIHJlcGV0YXQgbnUgcmVzcGVjdGEgcmVndWxpbGUuDQoJDQoJdGF2aQ0KCQ0K DQo= ------_=_NextPart_001_01C3BB0C.53F83344 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjUIAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA4gQAAAAAAADmAAENgAQAAgAAAAIAAgABBYAD AA4AAADTBwwABQAKAC4AMwAFAFsBASCAAwAOAAAA0wcMAAUACgAuADQABQBcAQEJgAEAIQAAAEEz ODIxOEJEMUI5MjlCNDNBNUQ1QTk3RTMxNTcxMkY0AB8HAQOQBgC0FgAAOAAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAADAAAABSAEUAOgAgAFsAcwBvAF0A IABlAGcAYQBsACAAaQBuAGMAYQByAGMAYQB0AGUAAABAADkARDP4Uwy7wwEfAD0AAQAAAAoAAABS AEUAOgAgAAAAAAACAUcAAQAAACoAAABjPXVzO2E9IDtwPU1TTGFiO2w9U0VSVkVSLTAzMTIwNTA4 NDY1MVotMwAAAB8ASQABAAAAMAAAAFIAZQA6ACAAWwBzAG8AXQAgAGUAZwBhAGwAIABpAG4AYwBh AHIAYwBhAHQAZQAAAEAATgAAY7rFmLnDAR8AWgABAAAAIgAAAE8AYwB0AGEAdgBpAGEAbgAgAFAA dQByAGQAaQBsAGEAAAAAAAIBWwABAAAAPQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE9jdGF2 aWFuIFB1cmRpbGEAU01UUAB0YXZpQGNzLnB1Yi5ybwAAAAACAVwAAQAAABQAAABTTVRQOlRBVklA Q1MuUFVCLlJPAB8AXQABAAAAIgAAAE8AYwB0AGEAdgBpAGEAbgAgAFAAdQByAGQAaQBsAGEAAAAA AAIBXgABAAAAPQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE9jdGF2aWFuIFB1cmRpbGEAU01U UAB0YXZpQGNzLnB1Yi5ybwAAAAACAV8AAQAAABQAAABTTVRQOlRBVklAQ1MuUFVCLlJPAB8AZgAB AAAACgAAAFMATQBUAFAAAAAAAB8AZwABAAAAHgAAAHQAYQB2AGkAQABjAHMALgBwAHUAYgAuAHIA bwAAAAAAHwBoAAEAAAAKAAAAUwBNAFQAUAAAAAAAHwBpAAEAAAAeAAAAdABhAHYAaQBAAGMAcwAu AHAAdQBiAC4AcgBvAAAAAAAfAHAAAQAAACgAAABbAHMAbwBdACAAZQBnAGEAbAAgAGkAbgBjAGEA cgBjAGEAdABlAAAAAgFxAAEAAAAbAAAAAcO6fnm1hYkLBmkkTuyQG7IJAl1XKwAjZNHNAB8AdAAB AAAALAAAAHMAbwBAAGEAdABsAGEAbgB0AGkAcwAuAGMAcwAuAHAAdQBiAC4AcgBvAAAAHwAaDAEA AAAcAAAATwB2AGkAZABpAHUAIABQAGwAYQB0AG8AbgAAAB8AHQ4BAAAAKAAAAFsAcwBvAF0AIABl AGcAYQBsACAAaQBuAGMAYQByAGMAYQB0AGUAAAACAQkQAQAAAMUOAADBDgAABzAAAExaRnWrg5CL AwAKAHJjcGcxMjWCMgNDaHRtbDEDMD8BAwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYI VQeyEdUOUQMB3RDXMgYABsMR1TMERhDZbxLrEeMI7wn3OxjPDjA1OxHSDGBjAFALCQFkMzaTEWAL pTQgEAIqXA6yvQGQZxTwCqMR4x3oNBTwADwhRE9DVFlQAEUgSFRNTCBQAFVCTElDICItIC8vVzND IYBEVCJEIJQzLjIhgEVOnCI+Hu0ejyPBMTgf8G8goiMPJB8mkDMdgCVwRXxBRCXNDvEm7ylvJPQ2 QQ7wPE1FVEEHsEExLGA9IkcJ8ASQYXRFBbAiEtBPTlQi0FQTLPAF4UV4EPFuZ2U9BlJ2EzEvQQCQ AiAgNhAuMC42HXA5LjEnIv4qzyUDNzcf8FRJKFRMRSXONA7wUmUAOiBbc29dIGVqZwdAIAuAYwrA NcB06mUkbjUf8C8zTzF/JkVfNJE3UChPJp87JDURYDwAQk9EWSBkaXL6PTtAcjqQOwMAIQMwPaGc ZG8A4D2hCrFccRiw/z2hEPADMD4FEWA6uxzxO7+IZzk2H/BESVY92WcAAEAXOtk2NENPQGJNynU7 QHUHgWMgBTELYIZtCHEFEC4gVG8tYLZhNZABAGVIYC1BIDXAZz1QBZAtYCBzSGBG4G7bR5BJQSAD gUhgbkbwCsBPRsBKMjk8QYV0aBjQYYpkCHEsSmFpIGILgN8u8AtgSbBKIACQczYQR6D7AyBJsWYA 0EhgThABkE1Q/mQKwE1QC4BPEE3BTVBI4ps+wArBb0tvQaNzdS7g+06ACJAuUzA62QHAPecKovc9 5wpxJHwwKBEh4EMbVQi/QJ9Br0K/Q89E31urSQOg/mNIol7AR0AFEAeBNhBPYP1QUHIAwFMAAxBQ gVKwAjBXSjIA0AWwZEkSbAdwYmxhaksRTwFvToBHQHV/UwADoFFvWZIBAAtRSbB0P0gAXpFgYDVg RuBI8nUg+wnAZWFpAZA2EGGRBbBQAvdJsE1QShJ1TbBH8FNvVH//VY9Wn1evWL9Zz1rfW+9c/wts jzszOB2AJm5ic+ZwAoA9+CdhAUBwf2h//2mPap9rr3LPbc9u33IPcP/7ff9GqCx2D3cfeC95P3pP P3tffG99f36Pf5+GZ092+UiAaXWB34Lvg/+FD4YfF4cviD89AEwgMEtRVc5PLfA9VkmgdHlgYC4x AEFSR0lOLVJJxkcgoDTgMHB4IvE9+P8KsRACPwU/oz9hP/+S7x8b/xFgnMCTz4lPil+Lb5nnPoDW aRzSJHw0JVFGLdFOUbp6llAynksL4pnJLaXC2k8FEGcLgDVxTQeQSbDfLuClw6ItLBA88VI9203B XwqBme9zpj0AnktimclG7QNhOp0MH+Evq4qR2Yzw7mMBkI0QA5FQCHA9YAtgb2MPm39z4pzRW01x O0BvQjqwMkBjcy5isGL+LgNgNTCnf6iPqZ+qr6u/v7fEBmACMK1vrn+vh1cJgCIgDiAvMy8B0DAz kCAyOjIzEFBNtR//ti+3P7hPuV/BtUggux+8L9+vh7Evsj+zRDUQQC1gC2D7AjAEAC60d78fwC/B P8JP88NfzhVDY8T/xg/HH8wP380fzi/PP7nuZ6BqBZC7D//SX694NMzHr8i/s0Q1p9QPv9Uf1i/g /+IP4x8k1jWd4f4vo1Lbb3W/ji+PP5BP6G//468f4eTsmGPuH5rvm/86u/ugUB/wUO//oSmgn6Gv or97o8+k3U8DoL3BTVC+gETfBZC+kL5i7MC+sDm+sBFg/CswvlFNUI0E3a/yr7M19lALYC1wbuPP 5N/l73NcaztAdHk8BChvjRMLUEDebQ3gDoA1EByQLQtgtMCrtKQEz2cF6j6vaXcOgP82ENosAp8D r+O/DS8OPwlP/wpfEd8P7xD/Eg8TH9Nv/1//sq4Xv3Q/dUoc3x3vHv8gD/8hHyIvIz8kTyVfJm91 LLAA7lAoXxjPr5ZWSGBfQk2Q6UnwICdM4nlJ0FFACBB4Y2snZ4EbUEkRTOAg/naxDxtPsyZPcWRw SFFJIf9fQD7QRxAwITBwTvAUvxXP7xbfK58sr6/Dc2EAplDyQCZtZIBhAGVm2fFpdv1IAERPMmcC YjBRIFBQYjB/pmH6MEmBMJ8xrxx0LpFw/wfwTlE8FUlRTnBJEuC/NZ+/Nq83vzjPr7RNd07xcGbA z0NQThBPQS6Rbm9l0EzE/01QPR8+Lxx0M8k8JGKxYsD/QIJlgKbwRsJBP0JPQ19Eb59Ff6/DZgA/ wPyRZXhkgL5vZhDKgGFgsPFG0HhfYP8/8kkvSj9LSmbAYhFAAf6g+4GggUA7Tc9O30/vWU9aX91b aUQv02EASKQtYhEuMv+BkOCgZ4DgkZZAZ0H+oEDxfzMSU3AzYVVPVl8cdLDxSfwvT1OxmbA6wTBh leAuUX/gr10PWx4uMUhACDAvgGW+dGUQQJJmP2dPWzxmO5DHOtDdgDNhb3BlU2DKoH9goTrQZOE7 YGI/Y08cdEn/uvBuAEDwAXFA4EiAbVFggn9t5UbwRtJT0E0hM2HswC1/pPBqT2tfWzxucTvRleB1 /zshLpBqP3VvWy1G0PogpmD/bu9v/9/HMARG0m1BczEH8P9G8JlwYHFzIS7wB+B4MHex/W4hdmER QPFucXOROqFIgP9H8FQRZi95X1stS9Au0DQyf3vPfN8cdGFQflFUEGDALr+Cb4N/Wz+JP4pPi1lB huH/uuE8cIDgVPBG4H8hL0ABcf+64YEzdBN3hDAEbfC68Fgwzy6Che+G/xx0bnVG0PLA/5VBblKM D40fhI9uAH+BLtB3YIKLAbBgcmEhMyA7AGz/lf+XD4ss4DKPZZArkq+Tv9EcdE4qKHQTKXeLgQFj R6DZ8T8gTm3hO2BQ+5IUQPAsmr+bz4sskE+RVL+fP6BPycWV76W/mA5vOqD7uuA6MGE80FDPKW8q e2kzv21AM1BgATujSJBU4HBfUv8zFVTwZLRMoo+hqS+qPxx0/3OVq8+s35geOsBksPOAkNv/iP+5 X44eR2FA8YHQCABNQPZpOsFggGFIgECQYIBgAf9ucUcTtW+2fzK1TNDgQH+B81RCOjFmb1QAOjBg gi6R/XtxZ01AvL+9z4ssSKaSBV8wYFQAmTHdgJmxdUbwTv/B/8MPMqWVoHHhO0DGr8e/73p+YECj 94GEaTxQMBT8gNdpwEyRCBBnU2BtYAFUIftHYEzwKEABeACLINOBghD/j1HLr8y/iAWrv8+fbF+y 1v9pMgZxbUPWwHuRZLFNQEbQ/9hv2X+LLC6RU3BlMW5x+iD9YIFtaeRlIC9QzjTVv9bPnzKlghB/ 0fogLzByKbyv/96Pix/mD+cf6C9RH1Iv8+H/YMBhckBL6++wjyp7lSBBHefwj/Gf6wB2b25EnbLi n2/jrz8oSKY8JXZM4VQAY//o7+n/6w/sH+0vLbO7UXHRL/dQgfGesNGhdTtgU2n/xnGkr/vf/O8C LwM/Xls7kv86MfbP998cdMV1P+BG0tQR/2CRX5ZgQGEhjxKQGWSxrsH/c9Eu0QUPBh/IzwxlyrFu 3/8JfzKWv7Cacp2llSAOvw/P/wQsMCI6MDvgR1LFc2YAczTvC95Agjzh7oNzLpDVrxOf+UsoZXqe sTpCFh8XLwQs/+E0GllXxTAho/Yf7yD/GD3/wMFTwYBxR3EdwDqQacCZMd8cvx3PS0WSFDowcoDg vJ//Jg8EDyzvLf8vD/4f/y8vr/8wvzHPMt8z70ZWOG/z//UK/zsPPB89Lz4/P09AX0FvQn/nQ49E n/TtT1BGjzl/9Vb+TW5BKX8qj7eGYDIOcigE/4BAxTINA7MgVPBTYGFSZLH9WHFlklLUIhmA+iA1 bzZ/fzePSc9K3/WD9eBmAMSALf5vZRBMf02PFMRzUNLxwQD9aVFwxYBmAWCTsyHyoYhiObujbW+A wiSQCAR1Z/9/wk/RDp9Tb1R/VY9Wn/Vl/xmymZBYr1m/19fSoNRypJD/c0Gz+55gTvHSsJ3RbkRe YPlR4iJVXAHKBl8PYB9hL/9iP2NPOr9l38PaaXVPhX6k/8GzGaJ/ErgQj7B3coVS3CHr2+GkJi53 QCLKAPKhcQ//ch/45mtvbH9tj26fb6/1g//T8Eew4IDvcdKwryDA8rNx+7UAanFDUDNcMrNRfX94 YO1+qTzJCZWgYstQ8t9+fz/yGnffeO8UxNwhu2Fnaf4id0F6f3uPfJ+Fr4a/cL//R09IX5Evkj+T T5RflW+Wf/+Xj5ifma+av5vPi7+Mz43fP5/voP8HiyNRwCDUMGwt//n0iE+JX6tFwEDvYbuh71C/ 9dFoEdRxUhQj5O6AdCSQ/kz2oGo02E+jf9CfpeIpQf/gwLMRDSCsT61foazLEabP/6ffFMQpMU/w 04G8UaoidcD/1XFRcMEQ0/D6gO6jGTi2Af9pQk8hgIG0cQ0CT2LccLDQ/7A/sU+hrMGBs2+0f8Qm XAD+dVuRUm+7X7xvaiZowcohj3PyXqFqAUwwbkdXd3H+ImjRTzAfMVFwDgHEonVxfxWQypBowVif vn/kpvKhZ/Pc0FEAbSLAn8Gvoayv//fLj8yfHFRh+iDdUeJg1VDf0+HAMFwBAGHykmFRsMBw33Vx DVDHn8ivqOV15UGhoH8kcc3/zw+hr9bP19/Y6Un7W7GmAHMM0dFXagUoBNKk/9JxpaAOUa+ygKFo AlFx039/1I9nNQgSXnHN79qfzM96/6vxDVB1IQ0gFfAcgQ3w42//5H/M3Q4w4VDEggBxEmDSYvd2 ArcA1iF1JGEM0HYBXXD+ZOBP4V/iZQ0gxGBYQfKS+8YhxGBjdEHtL+4yDSABwP/YkIsA1o/or9iv 8u/z/xD7X/pQwI/2z/Tf+So1+fEv8EZPTlT6SY/H9aCP1j/uEv4o+0juA/tP7XY3Mm39AVD6QPkM MBTQ/RBCAExPQ0tRVU9U9kX9fwGfZ/6x7i8HL+2jxDU4BDJPRFkDHQLACwivCzE3/QFIVE1MBfpA fQ1gAAAAHwA1EAEAAACKAAAAPAAzADYAQwA4ADEANgA0AEEARQAwAEMANgBDAEEANAA5ADgANwBD ADMARQBDADgAOABBADEAQgBCADQAMQA2AEEAMAAxADQANwAxADkAQABzAGUAcgB2AGUAcgAuAG0A aQBjAHIAbwBzAG8AZgB0AC0AbABhAGIALgBwAHUAYgAuAHIAbwA+AAAAAAAfAEcQAQAAAB4AAABt AGUAcwBzAGEAZwBlAC8AcgBmAGMAOAAyADIAAAAAAAsA8hABAAAAHwDzEAEAAAA8AAAAUgBFACUA MwBBACAAWwBzAG8AXQAgAGUAZwBhAGwAIABpAG4AYwBhAHIAYwBhAHQAZQAuAEUATQBMAAAACwD2 EAAAAABAAAcw9Cr3DAy7wwFAAAgwBh8EVAy7wwEDAN4/6f0AAAMA8T8JBAAAHwD4PwEAAAAcAAAA TwB2AGkAZABpAHUAIABQAGwAYQB0AG8AbgAAAAIB+T8BAAAAXQAAAAAAAADcp0DIwEIQGrS5CAAr L+GCAQAAAAAAAAAvTz1NU0xBQi9PVT1GSVJTVCBBRE1JTklTVFJBVElWRSBHUk9VUC9DTj1SRUNJ UElFTlRTL0NOPU9WSURJVVBMAAAAAB8A+j8BAAAAKgAAAFMAeQBzAHQAZQBtACAAQQBkAG0AaQBu AGkAcwB0AHIAYQB0AG8AcgAAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAA AAAAAC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHwAwQAEAAAAS AAAATwBWAEkARABJAFUAUABMAAAAAAAfADFAAQAAABIAAABPAFYASQBEAEkAVQBQAEwAAAAAAB8A MkABAAAAHgAAAHQAYQB2AGkAQABjAHMALgBwAHUAYgAuAHIAbwAAAAAAHwAzQAEAAAAeAAAAdABh AHYAaQBAAGMAcwAuAHAAdQBiAC4AcgBvAAAAAAAfADhAAQAAABIAAABPAFYASQBEAEkAVQBQAEwA AAAAAB8AOUABAAAABAAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGELK8Rp4DAAcQ7QgAAAMAEBAA AAAAAwAREAAAAAAeAAgQAQAAAGUAAABNVUxUVU1FU0NQVExBTVVSSVJJVE9BVEFJREVFQUVSQUNB REVDQVRTQVRVTkFNREVNQU5BTlVNQVJVTERFVEhSRUFEVVJJLE1BSUJJTkVMQVNBTVNJU1RFTVVM U0FGQUNBQVNUAAAAAAIBfwABAAAARQAAADwzNkM4MTY0QUUwQzZDQTQ5ODdDM0VDODhBMUJCNDE2 QTAxNDcxOUBzZXJ2ZXIubWljcm9zb2Z0LWxhYi5wdWIucm8+AAAAAOj0 ------_=_NextPart_001_01C3BB0C.53F83344-- From so@atlantis.cs.pub.ro Fri Dec 5 17:47:08 2003 From: so@atlantis.cs.pub.ro (Cosmin Arad) Date: Fri, 5 Dec 2003 09:47:08 -0800 (PST) Subject: [so] challenge Message-ID: <20031205174708.27894.qmail@web60508.mail.yahoo.com> Salut, Spre rusinea mea am constatat ca implementarea pe care am propus-o pentru un semafor generalizat pe Windows contine o greseala de sincronizare. Iata ca, o solutie la o problema de sincronizare este corecta pana se dovedeste contrariul. Va provoc sa gasiti si voi greseala pentru ca este mai interesant in felul asta. Primii 5 dintre voi, din fiecare grupa, care trimit un email cu greseala gasita, mie sau laborantului vostru, vor primi un bonus (5%) la laborator. Studentii din grupele 341CA si 341CA au avut un avantaj pentru ca stiu de mai mult timp de lucrul asta dar nu au profitat de el. Un singur student (Mihai Murgan) a reusit sa gaseasca bugul pana acum, deci competitia este deschisa. Chiar daca bonusul (ca punctaj) nu e chiar ademenitor castigati mult la impresia artistica :D Bafta, Cosmin PS Imi cer scuze fata de aceia dintre voi care ati folosit implementarea in vreo tema, considerand-o corecta :D __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree From so@atlantis.cs.pub.ro Fri Dec 5 22:37:40 2003 From: so@atlantis.cs.pub.ro (Dorin Moise) Date: Sat, 06 Dec 2003 00:37:40 +0200 Subject: [so] aiocb.aio_sigevent Message-ID: <200312052237.hB5Mbf3W005891@k.k.ro> Sa inteleg ca raspunsul ioanei ramane oficial? Vad ca nici unul dintre asistenti nu mi-a raspuns.... PS: Cand va fi corectata tema 1 la grupa 345CA? ----------------------------------------- .dorin moise Ioana Cutcutache so@atlantis.cs.pub.ro : Daca te referi la cum determini care din operatiile asincrone s-a terminat (daca ai pornit mai multe) folosesti functia aio_error si verifici fiecare structura aiocb asociata unei operatii asincrone pornite. Aio_error iti intoarce EINPROGRESS daca operatia nu s-a terminat inca. In felul asta vezi care s-au terminat si faci cleanup-ul (inchidere fisier) si ce mai ai nevoie sa faci. ----- Original Message ----- From: "Dorin Moise" To: Sent: Thursday, December 04, 2003 9:30 PM Subject: [so] aiocb.aio_sigevent > > > Cum ar trebui sa afle un "signal handler" ce operatie AIO s-a incheiat?!? > > Spre exemplu, unul din cele X threaduri incepe o operatie asincrona - dupa > ce mai intai a deschis fisierul pe care "opereaza" - si specifica un semnal > care sa fie "declansat" cand operatia se incheie. Intrebarea e : cine va > inchide fisierul?!? > Thanks. > ----------------------------------------- > .dorin moise > > Sentimente.ro - www.sentimente.ro Peste 50.000 de prieteni te asteapta! From so@atlantis.cs.pub.ro Sat Dec 6 05:25:48 2003 From: so@atlantis.cs.pub.ro (Florin Pop) Date: Sat, 6 Dec 2003 07:25:48 +0200 (E. Europe Standard Time) Subject: [so] La multi ani! References: <20031205174708.27894.qmail@web60508.mail.yahoo.com> Message-ID: <3FD1685C.000013.00576@einstein> --------------Boundary-00=_0FKG8WA1VA4000000000 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_0FKG36E1VA4000000000" --------------Boundary-00=_0FKG36E1VA4000000000 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tuturor celor care poarta numele Sfantului Nicolae, si nu numai, tuturor celor care intampina cu bucurie sarbatorile de iarna, le urea La multi an= i, sanatate lor si celor dragi, bunavoire si spor la munca.=0D =0D Sarbatori fericite! --------------Boundary-00=_0FKG36E1VA4000000000 Content-Type: Text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tuturor celor care poarta numele Sfantului Nicolae, si nu numai, tut= uror celor care intampina cu bucurie sarbatorile de iarna, le urea La mul= ti ani, sanatate lor si celor dragi, bunavoire si spor la munca.

Sarbatori fericite!

______________________= ______________________________
<= A href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&lang=3D9">= 3D""

IncrediMail - Email has= finally evolved - = Click Here --------------Boundary-00=_0FKG36E1VA4000000000-- --------------Boundary-00=_0FKG8WA1VA4000000000 Content-Type: unknown/unknown; name="IMSTP.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj 1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5 BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs= --------------Boundary-00=_0FKG8WA1VA4000000000-- From so@atlantis.cs.pub.ro Sat Dec 6 07:48:19 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Fri, 5 Dec 2003 23:48:19 -0800 (PST) Subject: [so] aiocb.aio_sigevent In-Reply-To: <200312052237.hB5Mbf3W005891@k.k.ro> Message-ID: <20031206074819.23998.qmail@web41008.mail.yahoo.com> --0-77538153-1070696899=:20869 Content-Type: multipart/alternative; boundary="0-1013990624-1070696899=:20869" --0-1013990624-1070696899=:20869 Content-Type: text/plain; charset=us-ascii Salut, Raspunsul oficial pt cazul in care folosesti semnale pt notificare ar fi : structura sigevent din componenta structurii aiocb contine si un camp sigev_value ce indica valoarea trimisa cu semnalul. Actiunea tipului de semnal pe care il ai in vedere trebuie setata folosind sigaction. Valorea va putea fi preluata in handler din structura siginfo_t primita ca parametru. Ai aici un exemplu atasat (necomentat, dar ar tb sa fie destul de usor de inteles). George Dorin Moise wrote: Sa inteleg ca raspunsul ioanei ramane oficial? Vad ca nici unul dintre asistenti nu mi-a raspuns.... PS: Cand va fi corectata tema 1 la grupa 345CA? ----------------------------------------- .dorin moise Ioana Cutcutache so@atlantis.cs.pub.ro : Daca te referi la cum determini care din operatiile asincrone s-a terminat (daca ai pornit mai multe) folosesti functia aio_error si verifici fiecare structura aiocb asociata unei operatii asincrone pornite. Aio_error iti intoarce EINPROGRESS daca operatia nu s-a terminat inca. In felul asta vezi care s-au terminat si faci cleanup-ul (inchidere fisier) si ce mai ai nevoie sa faci. ----- Original Message ----- From: "Dorin Moise" To: Sent: Thursday, December 04, 2003 9:30 PM Subject: [so] aiocb.aio_sigevent > > > Cum ar trebui sa afle un "signal handler" ce operatie AIO s-a incheiat?!? > > Spre exemplu, unul din cele X threaduri incepe o operatie asincrona - dupa > ce mai intai a deschis fisierul pe care "opereaza" - si specifica un semnal > care sa fie "declansat" cand operatia se incheie. Intrebarea e : cine va > inchide fisierul?!? > Thanks. > ----------------------------------------- > .dorin moise > > Sentimente.ro - www.sentimente.ro Peste 50.000 de prieteni te asteapta! _______________________________________________ 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-1013990624-1070696899=:20869 Content-Type: text/html; charset=us-ascii

Salut,

Raspunsul oficial pt cazul in care folosesti semnale pt notificare ar fi : structura sigevent din componenta structurii aiocb contine si un camp sigev_value ce indica valoarea trimisa cu

semnalul. Actiunea tipului de semnal pe care il ai in vedere trebuie setata folosind sigaction. Valorea va putea fi preluata in handler din structura siginfo_t primita ca parametru.

Ai aici un exemplu atasat (necomentat, dar ar tb sa fie destul de usor de inteles).

George

Dorin Moise <ddy@k.ro> wrote:

Sa inteleg ca raspunsul ioanei ramane oficial?
Vad ca nici unul dintre asistenti nu mi-a raspuns....

PS: Cand va fi corectata tema 1 la grupa 345CA?
-----------------------------------------
.dorin moise

Ioana Cutcutache so@atlantis.cs.pub.ro :

Daca te referi la cum determini care din operatiile asincrone s-a
terminat (daca ai pornit mai multe) folosesti functia aio_error si verifici
fiecare structura aiocb asociata unei operatii asincrone pornite. Aio_error
iti intoarce EINPROGRESS daca operatia nu s-a terminat inca. In felul asta
vezi care s-au terminat si faci cleanup-ul (inchidere fisier) si ce mai ai
nevoie sa faci.

----- Original Message -----
From: "Dorin Moise"
To:
Sent: Thursday, December 04, 2003 9:30 PM
Subject: [so] aiocb.aio_sigevent

>
>
> Cum ar trebui sa afle un "signal handler" ce operatie AIO s-a
incheiat?!?
>
> Spre exemplu, unul din cele X threaduri incepe o operatie asincrona -
dupa
> ce mai intai a deschis fisierul pe care "opereaza" - si specifica un
semnal
> care sa fie "declansat" cand operatia se incheie. Intrebarea e : cine va
> inchide fisierul?!?
> Thanks.
> -----------------------------------------
> .dorin moise
>
>

Sentimente.ro - www.sentimente.ro
Peste 50.000 de prieteni te asteapta!

_______________________________________________
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-1013990624-1070696899=:20869-- --0-77538153-1070696899=:20869 Content-Type: application/x-zip-compressed; name="sample.zip" Content-Transfer-Encoding: base64 Content-Description: sample.zip Content-Disposition: attachment; filename="sample.zip" UEsDBBQAAAAIACJOhi+xGwqaIwAAADEBAAAKAAAAc2FtcGxlL2Zpc8tJTCku TslJLEtKKUvKSUkqSynj5crBFKSmELEWYFU30IIAUEsDBBQAAAAIAAZOhi/K yahU7wEAAN0DAAANAAAAc2FtcGxlL3Rlc3QuY31SXWvbMBR9rn7FJWVFDk7m PIw9pCkU9kGhJNCwwdiGUWwpudSRjCWFpSX/vfc6X6sL9Yukc885uj5Xl2iL KpYarhW64epGXJ4AH8oKF2+wLs0UNlQd1tZ/9EGFt2jY1tq/hqNFcu1e06Bd MiY2DktYKVtWuhlJtAE8Lm1cp7SgNS4P0AfepC2zD7Vq1DoB8SyAvpqMgpE9 9wgfyj+2l7bcwY3HfKOqqIceac2JlIxbgdgJwbesFVq5ceXeiRFTEoM6i0Xb gyoCOgter62qNJdw6XXIWeoLdeZSsMUClM8brdiiWKkGFtGY36Ms+7sX6nUd tqSWV62YexFH66FXuanU0k/mt/n87vvd9Nts/KpKmsfJ6dYzfupycgxwLMS5 d0lmP+YPo/TqoEll9/f6SZawxpQwAVdrK3sGPaU4yx++zKb3v7hTNCCJcA1Z As/i4hj5NIIfKKhjiAFK7YsV0mxJjrqJFW9oHqS/0P8wyMGIrXYCFk+6cfLq kFdKvTxpZ+ThnCRjmtExzSFlmxusyJ36awf0f8UZQ5lSJesUKH1CeQadgl1s Q+v1qSvhIW20DcN2k1sX0GyJSBl+/cljmd7evy/hd+v2Ck79fXL7OIks6cgP NCSfMx4EU1lzCohTq1X0Wu4fTaNDbCz/sdi9AFBLAwQKAAAAAABBToYvAAAA AAAAAAAAAAAABwAAAHNhbXBsZS9QSwECFAAUAAAACAAiToYvsRsKmiMAAAAx AQAACgAAAAAAAAABACAAtoEAAAAAc2FtcGxlL2Zpc1BLAQIUABQAAAAIAAZO hi/KyahU7wEAAN0DAAANAAAAAAAAAAEAIAC2gUsAAABzYW1wbGUvdGVzdC5j UEsBAhQACgAAAAAAQU6GLwAAAAAAAAAAAAAAAAcAAAAAAAAAAAAQAP9BZQIA AHNhbXBsZS9QSwUGAAAAAAMAAwCoAAAAigIAAAAA --0-77538153-1070696899=:20869-- From so@atlantis.cs.pub.ro Sat Dec 6 11:43:43 2003 From: so@atlantis.cs.pub.ro (Mihai Iancu) Date: Sat, 6 Dec 2003 03:43:43 -0800 (PST) Subject: [so] WriteFile x-( In-Reply-To: <20031206074819.23998.qmail@web41008.mail.yahoo.com> Message-ID: <20031206114343.74306.qmail@web60301.mail.yahoo.com> --0-1010843226-1070711023=:73637 Content-Type: multipart/alternative; boundary="0-807777371-1070711023=:73637" --0-807777371-1070711023=:73637 Content-Type: text/plain; charset=us-ascii Nu reusesc sa ma prind cum merge WriteFile cu OVERLAPPED. In MSDN scrie If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the write operation starts at the offset specified in the OVERLAPPED structure and WriteFile may return before the write operation has been completed. In this case, WriteFile returns FALSE and the GetLastError function returns ERROR_IO_PENDING. This allows the calling process to continue processing while the write operation is being completed. The event specified in the OVERLAPPED structure is set to the signaled state upon completion of the write operation. Am incercat sa scriu intr-un fisier 10Mb si apoi 30 Mb totul se intampla instant si deci am crezut ca este ok sa intoarca TRUE writefile. Apoi am scris 100Mb si dureaza cam 3 secunde, dar functia WriteFile nu intoarce FALSE imediat, ci asteapta sa faca scrierea. Ce este ciudat este ca Eventul din OVERLAPPED este semnazat deci nu cred ca am gresit in totalitate apelurile de functii. codul este atasat --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-807777371-1070711023=:73637 Content-Type: text/html; charset=us-ascii

Nu reusesc sa ma prind cum merge WriteFile cu OVERLAPPED.

In MSDN scrie

<quote>

If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the write operation starts at the offset specified in the OVERLAPPED structure and WriteFile may return before the write operation has been completed. In this case, WriteFile returns FALSE and the GetLastError function returns ERROR_IO_PENDING. This allows the calling process to continue processing while the write operation is being completed. The event specified in the OVERLAPPED structure is set to the signaled state upon completion of the write operation.

</quote>

Am incercat sa scriu intr-un fisier 10Mb si apoi 30 Mb totul se intampla instant si deci am crezut ca este ok sa intoarca TRUE writefile.

Apoi am scris 100Mb si dureaza cam 3 secunde, dar functia WriteFile nu intoarce FALSE imediat, ci asteapta sa faca scrierea. Ce este ciudat este ca Eventul din OVERLAPPED este semnazat deci nu cred ca am gresit in totalitate apelurile de functii.

codul este atasat

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-807777371-1070711023=:73637-- --0-1010843226-1070711023=:73637 Content-Type: text/plain; name="wfx_test.cpp" Content-Description: wfx_test.cpp Content-Disposition: inline; filename="wfx_test.cpp" #include #include /* HELPS FOR FINDING THE ERRORS RETURNED BY THE FUNCTIONS */ void PostError(const char* msg, DWORD dwErr, bool bTerminate){ LPVOID lpMsgBuf; FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, dwErr, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language (LPTSTR) &lpMsgBuf, 0, NULL); printf("%s: %s\n", msg, (LPCSTR)lpMsgBuf); // Free the buffer. LocalFree( lpMsgBuf ); if (bTerminate) ExitProcess(3); } /* MAIN */ int main(){ //declare char *lpBuffer = (char*) HeapAlloc(GetProcessHeap(),0,100*1024*1024); DWORD dwBytesToWrite=100*1024*1024; DWORD dwBytesWritten; BOOL bResult; OVERLAPPED ovrLpd1; HANDLE hEvent; //create event hEvent = CreateEvent(NULL, FALSE, FALSE, NULL); if (hEvent == INVALID_HANDLE_VALUE){ printf("error CreateEvent\n"); ExitProcess(2); } //create the overlapped structure ovrLpd1.Offset = 0; ovrLpd1.OffsetHigh = 0; ovrLpd1.hEvent = hEvent; //others if (lpBuffer == NULL){ printf("error HeapAlloc()\n"); ExitProcess(1); } ZeroMemory((PVOID)lpBuffer,100*1024*1024); //create file HANDLE hFile = CreateFile( "junk.file", GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, FILE_FLAG_OVERLAPPED, NULL); if (hFile==INVALID_HANDLE_VALUE){ PostError("CreateFile: ",(int)GetLastError(), FALSE); ExitProcess(1); } printf("called WriteFile\n"); bResult = WriteFile( hFile, lpBuffer, dwBytesToWrite, NULL, &ovrLpd1); printf("called WriteFile end\n"); GetOverlappedResult(hFile, &ovrLpd1, &dwBytesWritten, FALSE); printf("%d\n", (int)dwBytesWritten); if (!bResult) PostError("WriteFile",GetLastError(), FALSE); else printf("File written - WriteFile returned TRUE ????\n"); printf("wating to finish async write\n"); WaitForSingleObject(hEvent, INFINITE); CloseHandle(hFile); HeapFree(GetProcessHeap(),0,lpBuffer); return 0; } --0-1010843226-1070711023=:73637-- From so@atlantis.cs.pub.ro Sat Dec 6 13:11:53 2003 From: so@atlantis.cs.pub.ro (Mihai Iancu) Date: Sat, 6 Dec 2003 05:11:53 -0800 (PST) Subject: [so] WriteFile x-( In-Reply-To: <20031206114343.74306.qmail@web60301.mail.yahoo.com> Message-ID: <20031206131153.78470.qmail@web60302.mail.yahoo.com> --0-1374431375-1070716313=:76435 Content-Type: text/plain; charset=us-ascii Raspuns: WriteFile intoarece true cand termina de scris sau daca este OVERLAPPED cand termina de facut pending, asa ca daca face pending intoarce true chiar daca operatia nu s-a terminat. deci programul dat merge bine (pana la proba contrarie) Iancu wrote: Nu reusesc sa ma prind cum merge WriteFile cu OVERLAPPED. In MSDN scrie If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the write operation starts at the offset specified in the OVERLAPPED structure and WriteFile may return before the write operation has been completed. In this case, WriteFile returns FALSE and the GetLastError function returns ERROR_IO_PENDING. This allows the calling process to continue processing while the write operation is being completed. The event specified in the OVERLAPPED structure is set to the signaled state upon completion of the write operation. Am incercat sa scriu intr-un fisier 10Mb si apoi 30 Mb totul se intampla instant si deci am crezut ca este ok sa intoarca TRUE writefile. Apoi am scris 100Mb si dureaza cam 3 secunde, dar functia WriteFile nu intoarce FALSE imediat, ci asteapta sa faca scrierea. Ce este ciudat este ca Eventul din OVERLAPPED este semnazat deci nu cred ca am gresit in totalitate apelurile de functii. codul este atasat --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard#include #include /* HELPS FOR FINDING THE ERRORS RETURNED BY THE FUNCTIONS */ void PostError(const char* msg, DWORD dwErr, bool bTerminate){ LPVOID lpMsgBuf; FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, dwErr, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language (LPTSTR) &lpMsgBuf, 0, NULL); printf("%s: %s\n", msg, (LPCSTR)lpMsgBuf); // Free the buffer. LocalFree( lpMsgBuf ); if (bTerminate) ExitProcess(3); } /* MAIN */ int main(){ //declare char *lpBuffer = (char*) HeapAlloc(GetProcessHeap(),0,100*1024*1024); DWORD dwBytesToWrite=100*1024*1024; DWORD dwBytesWritten; BOOL bResult; OVERLAPPED ovrLpd1; HANDLE hEvent; //create event hEvent = CreateEvent(NULL, FALSE, FALSE, NULL); if (hEvent == INVALID_HANDLE_VALUE){ printf("error CreateEvent\n"); ExitProcess(2); } //create the overlapped structure ovrLpd1.Offset = 0; ovrLpd1.OffsetHigh = 0; ovrLpd1.hEvent = hEvent; //others if (lpBuffer == NULL){ printf("error HeapAlloc()\n"); ExitProcess(1); } ZeroMemory((PVOID)lpBuffer,100*1024*1024); //create file HANDLE hFile = CreateFile( "junk.file", GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, FILE_FLAG_OVERLAPPED, NULL); if (hFile==INVALID_HANDLE_VALUE){ PostError("CreateFile: ",(int)GetLastError(), FALSE); ExitProcess(1); } printf("called WriteFile\n"); bResult = WriteFile( hFile, lpBuffer, dwBytesToWrite, NULL, &ovrLpd1); printf("called WriteFile end\n"); GetOverlappedResult(hFile, &ovrLpd1, &dwBytesWritten, FALSE); printf("%d\n", (int)dwBytesWritten); if (!bResult) PostError("WriteFile",GetLastError(), FALSE); else printf("File written - WriteFile returned TRUE ????\n"); printf("wating to finish async write\n"); WaitForSingleObject(hEvent, INFINITE); CloseHandle(hFile); HeapFree(GetProcessHeap(),0,lpBuffer); return 0; } --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-1374431375-1070716313=:76435 Content-Type: text/html; charset=us-ascii

Raspuns:

WriteFile intoarece true cand termina de scris sau daca este OVERLAPPED cand

termina de facut pending, asa ca daca face pending intoarce true chiar daca operatia

nu s-a terminat.

deci programul dat merge bine (pana la proba contrarie)

Iancu <mail2mihai@yahoo.com> wrote:

Nu reusesc sa ma prind cum merge WriteFile cu OVERLAPPED.

In MSDN scrie

<quote>

If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the write operation starts at the offset specified in the OVERLAPPED structure and WriteFile may return before the write operation has been completed. In this case, WriteFile returns FALSE and the GetLastError function returns ERROR_IO_PENDING. This allows the calling process to continue processing while the write operation is being completed. The event specified in the OVERLAPPED structure is set to the signaled state upon completion of the write operation.

</quote>

Am incercat sa scriu intr-un fisier 10Mb si apoi 30 Mb totul se intampla instant si deci am crezut ca este ok sa intoarca TRUE writefile.

Apoi am scris 100Mb si dureaza cam 3 secunde, dar functia WriteFile nu intoarce FALSE imediat, ci asteapta sa faca scrierea. Ce este ciudat este ca Eventul din OVERLAPPED este semnazat deci nu cred ca am gresit in totalitate apelurile de functii.

codul este atasat

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard#include
#include
/*

HELPS FOR FINDING THE ERRORS RETURNED BY THE FUNCTIONS

*/
void PostError(const char* msg, DWORD dwErr, bool bTerminate){
LPVOID lpMsgBuf;

FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
dwErr,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
(LPTSTR) &lpMsgBuf,
0,
NULL);
printf("%s: %s\n", msg, (LPCSTR)lpMsgBuf);
// Free the buffer.
LocalFree( lpMsgBuf );
if (bTerminate)
ExitProcess(3);
}
/*

MAIN

*/

int main(){
//declare
char *lpBuffer = (char*) HeapAlloc(GetProcessHeap(),0,100*1024*1024);
DWORD dwBytesToWrite=100*1024*1024;
DWORD dwBytesWritten;
BOOL bResult;
OVERLAPPED ovrLpd1;
HANDLE hEvent;
//create event
hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
if (hEvent == INVALID_HANDLE_VALUE){
printf("error CreateEvent\n");
ExitProcess(2);
}
//create the overlapped structure
ovrLpd1.Offset = 0;
ovrLpd1.OffsetHigh = 0;
ovrLpd1.hEvent = hEvent;
//others
if (lpBuffer == NULL){
printf("error HeapAlloc()\n");
ExitProcess(1);
}
ZeroMemory((PVOID)lpBuffer,100*1024*1024);
//create file
HANDLE hFile = CreateFile(
"junk.file",
GENERIC_WRITE,
0,
NULL,
OPEN_ALWAYS,
FILE_FLAG_OVERLAPPED,
NULL);
if (hFile==INVALID_HANDLE_VALUE){
PostError("CreateFile: ",(int)GetLastError(), FALSE);
ExitProcess(1);
}
printf("called WriteFile\n");
bResult = WriteFile(
hFile,
lpBuffer,
dwBytesToWrite,
NULL,
&ovrLpd1);
printf("called WriteFile end\n");
GetOverlappedResult(hFile, &ovrLpd1, &dwBytesWritten, FALSE);
printf("%d\n", (int)dwBytesWritten);
if (!bResult)
PostError("WriteFile",GetLastError(), FALSE);
else
printf("File written - WriteFile returned TRUE ????\n");
printf("wating to finish async write\n");
WaitForSingleObject(hEvent, INFINITE);

CloseHandle(hFile);
HeapFree(GetProcessHeap(),0,lpBuffer);
return 0;
}

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-1374431375-1070716313=:76435-- From so@atlantis.cs.pub.ro Sat Dec 6 13:50:04 2003 From: so@atlantis.cs.pub.ro (Horatiu Dan) Date: Sat, 6 Dec 2003 15:50:04 +0200 Subject: [so] comunicare task pentru thread Message-ID: Salut am si eu o intrebare... cand serverul primeste o cerere de la un client, verifica ce thread care realizeaza acea operatie e mai putin incarcat si apoi spune unui thread sa inceapa operatia respectiva. cum se face aceasta comunicare? cum specific unui anumit thread care realizeaza o operatie ca el este cel care trbuie sa o indeplineasca? multumesc h From so@atlantis.cs.pub.ro Sat Dec 6 14:01:34 2003 From: so@atlantis.cs.pub.ro (Cristian Zamfir) Date: Sat, 6 Dec 2003 16:01:34 +0200 Subject: [so] comunicare task pentru thread In-Reply-To: References: Message-ID: <200312061601.34505.zamfir@fx.ro> On Saturday 06 December 2003 15:50, Horatiu Dan wrote: cred ca o varianta, cel putin pe linux, ar fi cu variabile conditie, si cind primesti cerere de la un client nou, dai signal-ul corespunzator. > Salut > am si eu o intrebare... > cand serverul primeste o cerere de la un client, verifica ce thread care > realizeaza acea operatie e mai putin incarcat si apoi spune unui thread sa > inceapa operatia respectiva. cum se face aceasta comunicare? cum specific > unui anumit thread care realizeaza o operatie ca el este cel care trbuie sa > o indeplineasca? > > multumesc > > h > _______________________________________________ > so mailing list > so@atlantis.cs.pub.ro > http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so From so@atlantis.cs.pub.ro Sat Dec 6 14:09:42 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Sat, 06 Dec 2003 16:09:42 +0200 Subject: [so] comunicare task pentru thread In-Reply-To: References: Message-ID: On Sat, 6 Dec 2003 15:50:04 +0200, Horatiu Dan wrote: > Salut > am si eu o intrebare... > cand serverul primeste o cerere de la un client, verifica ce thread care > realizeaza acea operatie e mai putin incarcat si apoi spune unui thread > sa > inceapa operatia respectiva. cum se face aceasta comunicare? cum specific > unui anumit thread care realizeaza o operatie ca el este cel care trbuie > sa o indeplineasca? > Exista multe alternative. Puteti sa folositi orice doriti voi. Pentru claritate, specificati in README ce alegere ati facut. tavi From so@atlantis.cs.pub.ro Sat Dec 6 14:25:26 2003 From: so@atlantis.cs.pub.ro (Horatiu Dan) Date: Sat, 6 Dec 2003 16:25:26 +0200 Subject: [so] comunicare task pentru thread References: Message-ID: Am scris acest mail pentru a primi o sugestie, deoarece nu prea stiam cum as putea face... va multumesc... ----- Original Message ----- From: "Octavian Purdila" To: Sent: Saturday, December 06, 2003 4:09 PM Subject: Re: [so] comunicare task pentru thread > On Sat, 6 Dec 2003 15:50:04 +0200, Horatiu Dan > wrote: > > > Salut > > am si eu o intrebare... > > cand serverul primeste o cerere de la un client, verifica ce thread care > > realizeaza acea operatie e mai putin incarcat si apoi spune unui thread > > sa > > inceapa operatia respectiva. cum se face aceasta comunicare? cum specific > > unui anumit thread care realizeaza o operatie ca el este cel care trbuie > > sa o indeplineasca? > > > > Exista multe alternative. Puteti sa folositi orice doriti voi. Pentru > claritate, specificati > in README ce alegere ati facut. > > tavi > _______________________________________________ > so mailing list > so@atlantis.cs.pub.ro > http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so > From so@atlantis.cs.pub.ro Sat Dec 6 15:15:58 2003 From: so@atlantis.cs.pub.ro (Ruxi Jitianu) Date: Sat, 06 Dec 2003 17:15:58 +0200 Subject: [so] gethostbyname References: <20031206131153.78470.qmail@web60302.mail.yahoo.com> Message-ID: <3FD1F2AE.6040101@pcnet.ro> Buna! Are cineva idee...gethostbyname nu functioneaza cum trebuie pe XP? Merci! Ruxi From so@atlantis.cs.pub.ro Sat Dec 6 18:03:09 2003 From: so@atlantis.cs.pub.ro (Mihai Iancu) Date: Sat, 6 Dec 2003 10:03:09 -0800 (PST) Subject: [so] WaitForMO In-Reply-To: <3FD1F2AE.6040101@pcnet.ro> Message-ID: <20031206180309.48544.qmail@web60301.mail.yahoo.com> --0-1662238864-1070733789=:47329 Content-Type: text/plain; charset=us-ascii WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS. Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite unui thread dam raspuns de too busy sau gasim o alternativa? --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-1662238864-1070733789=:47329 Content-Type: text/html; charset=us-ascii

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-1662238864-1070733789=:47329-- From so@atlantis.cs.pub.ro Sat Dec 6 19:05:32 2003 From: so@atlantis.cs.pub.ro (Cristian Zamfir) Date: Sat, 6 Dec 2003 21:05:32 +0200 Subject: [so] arhivele listei In-Reply-To: <200312061601.34505.zamfir@fx.ro> References: <200312061601.34505.zamfir@fx.ro> Message-ID: <200312062105.32815.zamfir@fx.ro> Cred ca nu mai functioneaza arhivele listei de discutii. Mi se spune ca nu e buna parola la logare. From so@atlantis.cs.pub.ro Sat Dec 6 19:11:08 2003 From: so@atlantis.cs.pub.ro (Mihai Iancu) Date: Sat, 6 Dec 2003 11:11:08 -0800 (PST) Subject: [so] WaitForMultipleObjects In-Reply-To: <20031206180309.48544.qmail@web60301.mail.yahoo.com> Message-ID: <20031206191108.8785.qmail@web60309.mail.yahoo.com> --0-1095138327-1070737868=:8266 Content-Type: text/plain; charset=us-ascii Stie cineva din discutiile anterioare daca pe windows pt notificarea terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal, caci WaitForMO are limita de handles Mihai Iancu wrote: WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS. Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite unui thread dam raspuns de too busy sau gasim o alternativa? --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-1095138327-1070737868=:8266 Content-Type: text/html; charset=us-ascii

Stie cineva din discutiile anterioare daca pe windows pt notificarea

terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu

pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-1095138327-1070737868=:8266-- From so@atlantis.cs.pub.ro Sat Dec 6 19:21:55 2003 From: so@atlantis.cs.pub.ro (Toma Monica) Date: Sat, 6 Dec 2003 11:21:55 -0800 (PST) Subject: [so] system Message-ID: <20031206192155.21263.qmail@web10409.mail.yahoo.com> Listarea fisierelor din director, folosind "ls" putem folosi si apelul "system"? ===== I dream of finding myself laughing! __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Sat Dec 6 22:10:25 2003 From: so@atlantis.cs.pub.ro (Catalin Constantin) Date: Sun, 7 Dec 2003 00:10:25 +0200 Subject: [so] arhivele listei References: <200312061601.34505.zamfir@fx.ro> <200312062105.32815.zamfir@fx.ro> Message-ID: <021a01c3bc45$c110b9d0$0201a8c0@catalin> Faza e ca dupa crash parolele au fost generate "random" or some. Iti recomand sa folosesti optiunea de Email My password. Catalin Constantin Bounce Software www.bounce-software.com ----- Original Message ----- From: Cristian Zamfir To: so@atlantis.cs.pub.ro Sent: Saturday, December 06, 2003 9:05 PM Subject: [so] arhivele listei Cred ca nu mai functioneaza arhivele listei de discutii. Mi se spune ca nu e buna parola la logare. _______________________________________________ so mailing list so@atlantis.cs.pub.ro http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so From so@atlantis.cs.pub.ro Sat Dec 6 22:12:42 2003 From: so@atlantis.cs.pub.ro (Catalin Constantin) Date: Sun, 7 Dec 2003 00:12:42 +0200 Subject: [so] system References: <20031206192155.21263.qmail@web10409.mail.yahoo.com> Message-ID: <023b01c3bc46$11b2f7e0$0201a8c0@catalin> Daca am inteles eu bine la laborator se pare ca e OK sa folosim si system si sa facem "catch" la output. Corectati-ma daca ma insel ! Catalin ----- Original Message ----- From: Toma Monica To: so Sent: Saturday, December 06, 2003 9:21 PM Subject: [so] system Listarea fisierelor din director, folosind "ls" putem folosi si apelul "system"? ===== 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 From so@atlantis.cs.pub.ro Sun Dec 7 07:47:00 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sat, 6 Dec 2003 23:47:00 -0800 (PST) Subject: [so] system In-Reply-To: <20031206192155.21263.qmail@web10409.mail.yahoo.com> Message-ID: <20031207074700.79926.qmail@web41009.mail.yahoo.com> --0-1237778507-1070783220=:77511 Content-Type: text/plain; charset=us-ascii Se poate folosi system Toma Monica wrote: Listarea fisierelor din director, folosind "ls" putem folosi si apelul "system"? ===== 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 --0-1237778507-1070783220=:77511 Content-Type: text/html; charset=us-ascii

Se poate folosi system

Toma Monica <moniqqus@yahoo.com> wrote:

Listarea fisierelor din director, folosind "ls" putem
folosi si apelul "system"?

=====

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 --0-1237778507-1070783220=:77511-- From so@atlantis.cs.pub.ro Sun Dec 7 07:50:45 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sat, 6 Dec 2003 23:50:45 -0800 (PST) Subject: [so] WaitForMO In-Reply-To: <20031206180309.48544.qmail@web60301.mail.yahoo.com> Message-ID: <20031207075045.71491.qmail@web41014.mail.yahoo.com> --0-1274498641-1070783445=:70704 Content-Type: text/plain; charset=us-ascii Daca toate threadurile cu notificare de tip b au ajuns la MAXIMUM_WAIT_OBJECTS poti raspunde cu busy Mihai Iancu wrote: WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS. Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite unui thread dam raspuns de too busy sau gasim o alternativa? --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --0-1274498641-1070783445=:70704 Content-Type: text/html; charset=us-ascii

Daca toate threadurile cu notificare de tip b au ajuns la MAXIMUM_WAIT_OBJECTS poti

raspunde cu busy

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing --0-1274498641-1070783445=:70704-- From so@atlantis.cs.pub.ro Sun Dec 7 07:52:09 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sat, 6 Dec 2003 23:52:09 -0800 (PST) Subject: [so] WaitForMultipleObjects In-Reply-To: <20031206191108.8785.qmail@web60309.mail.yahoo.com> Message-ID: <20031207075209.97843.qmail@web41002.mail.yahoo.com> --0-754252525-1070783529=:97166 Content-Type: text/plain; charset=us-ascii E obligatorie folosirea functiei WaitForMultipleObjects, sau WaitForMultipleObjectsEx Mihai Iancu wrote:Stie cineva din discutiile anterioare daca pe windows pt notificarea terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal, caci WaitForMO are limita de handles Mihai Iancu wrote: WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS. Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite unui thread dam raspuns de too busy sau gasim o alternativa? --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --0-754252525-1070783529=:97166 Content-Type: text/html; charset=us-ascii

E obligatorie folosirea functiei WaitForMultipleObjects, sau WaitForMultipleObjectsEx

Mihai Iancu <mail2mihai@yahoo.com> wrote:

Stie cineva din discutiile anterioare daca pe windows pt notificarea

terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu

pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing --0-754252525-1070783529=:97166-- From so@atlantis.cs.pub.ro Sun Dec 7 08:35:38 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Sun, 7 Dec 2003 10:35:38 +0200 Subject: [so] WaitForMultipleObjects References: <20031207075209.97843.qmail@web41002.mail.yahoo.com> Message-ID: <001e01c3bc9d$18586740$2b0c6150@ioana> This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C3BCAD.DAF8FA20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable La firele de tip a nu se poate folosi WaitForSingleObjectEx?=20 ----- Original Message -----=20 From: George Ciobanu=20 To: so@atlantis.cs.pub.ro=20 Sent: Sunday, December 07, 2003 9:52 AM Subject: Re: [so] WaitForMultipleObjects E obligatorie folosirea functiei WaitForMultipleObjects, sau = WaitForMultipleObjectsEx Mihai Iancu wrote:=20 Stie cineva din discutiile anterioare daca pe windows pt notificarea terminarii unei operatii trebuie sa folosim WaitForMultipleObjects = obligatoriu pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un = semnal, caci WaitForMO are limita de handles Mihai Iancu wrote: WaitForMultipleObject are limita la handles de = MAXIMUM_WAIT_OBJECTS. Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi = atribuite unui thread dam raspuns de too busy sau gasim o alternativa? -------------------------------------------------------------------------= - Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard -------------------------------------------------------------------------= --- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard -------------------------------------------------------------------------= ----- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing ------=_NextPart_000_001B_01C3BCAD.DAF8FA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

La firele de tip a nu se poate folosi=20 WaitForSingleObjectEx?

----- Original Message -----

From:=20 George=20 Ciobanu

To: so@atlantis.cs.pub.ro

Sent: Sunday, December 07, 2003 = 9:52=20 AM

Subject: Re: [so]=20 WaitForMultipleObjects

E obligatorie folosirea functiei WaitForMultipleObjects, sau=20 WaitForMultipleObjectsEx

Mihai Iancu <mail2mihai@yahoo.com>= wrote:=20

Stie cineva din discutiile anterioare daca pe windows pt=20 notificarea

terminarii unei operatii trebuie sa folosim = WaitForMultipleObjects=20 obligatoriu

pt threaduri de tip b? sau e posibil si cu=20 WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> = wrote:

WaitForMultipleObject are limita la handles de=20 MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT = requesturi=20 atribuite

unui thread dam raspuns de too busy sau gasim o = alternativa?

Do you Yahoo!?
Protect=20 your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect=20 your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
New=20 Yahoo! Photos - easier uploading and = sharing ------=_NextPart_000_001B_01C3BCAD.DAF8FA20-- From so@atlantis.cs.pub.ro Sun Dec 7 08:53:01 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sun, 7 Dec 2003 00:53:01 -0800 (PST) Subject: [so] WaitForMultipleObjects In-Reply-To: <001e01c3bc9d$18586740$2b0c6150@ioana> Message-ID: <20031207085301.9805.qmail@web41015.mail.yahoo.com> --0-1279254571-1070787181=:8552 Content-Type: text/plain; charset=us-ascii Intrucat la cele de tip se cere folosirea APC-urilor este obligatoriu sa folosesti una din functiile de asteptare alertabile (printre care si WaitForSingleObjectEx). Oricum, in acest caz vei folosi pt citire/scriere ReadFileEx/WriteFileEx (APC-ul este de tip FileIOCompletionRoutine) Ioana Cutcutache wrote: La firele de tip a nu se poate folosi WaitForSingleObjectEx? ----- Original Message ----- From: George Ciobanu To: so@atlantis.cs.pub.ro Sent: Sunday, December 07, 2003 9:52 AM Subject: Re: [so] WaitForMultipleObjects E obligatorie folosirea functiei WaitForMultipleObjects, sau WaitForMultipleObjectsEx Mihai Iancu wrote: Stie cineva din discutiile anterioare daca pe windows pt notificarea terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal, caci WaitForMO are limita de handles Mihai Iancu wrote: WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS. Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite unui thread dam raspuns de too busy sau gasim o alternativa? --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --0-1279254571-1070787181=:8552 Content-Type: text/html; charset=us-ascii

Intrucat la cele de tip se cere folosirea APC-urilor este obligatoriu sa folosesti una din functiile de asteptare alertabile (printre care si WaitForSingleObjectEx). Oricum, in acest caz vei folosi pt citire/scriere ReadFileEx/WriteFileEx (APC-ul este de tip FileIOCompletionRoutine)

Ioana Cutcutache <ioana_c@idilis.ro> wrote:

La firele de tip a nu se poate folosi WaitForSingleObjectEx?

----- Original Message -----

From: George Ciobanu

To: so@atlantis.cs.pub.ro

Sent: Sunday, December 07, 2003 9:52 AM

Subject: Re: [so] WaitForMultipleObjects

E obligatorie folosirea functiei WaitForMultipleObjects, sau WaitForMultipleObjectsEx

Mihai Iancu <mail2mihai@yahoo.com> wrote:

Stie cineva din discutiile anterioare daca pe windows pt notificarea

terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu

pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing --0-1279254571-1070787181=:8552-- From so@atlantis.cs.pub.ro Sun Dec 7 13:12:20 2003 From: so@atlantis.cs.pub.ro (Toma Monica) Date: Sun, 7 Dec 2003 05:12:20 -0800 (PST) Subject: [so] nelamurire privind asincr. Message-ID: <20031207131221.69430.qmail@web10406.mail.yahoo.com> 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? ===== I dream of finding myself laughing! __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Sun Dec 7 13:43:02 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sun, 7 Dec 2003 05:43:02 -0800 (PST) Subject: [so] nelamurire privind asincr. In-Reply-To: <20031207131221.69430.qmail@web10406.mail.yahoo.com> Message-ID: <20031207134302.43698.qmail@web41013.mail.yahoo.com> --0-522652971-1070804582=:41073 Content-Type: text/plain; charset=us-ascii 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 --0-522652971-1070804582=:41073 Content-Type: text/html; charset=us-ascii

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 <moniqqus@yahoo.com> 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 --0-522652971-1070804582=:41073-- From so@atlantis.cs.pub.ro Sun Dec 7 15:02:47 2003 From: so@atlantis.cs.pub.ro (Toma Monica) Date: Sun, 7 Dec 2003 07:02:47 -0800 (PST) Subject: [so] nelamurire privind asincr. In-Reply-To: <20031207134302.43698.qmail@web41013.mail.yahoo.com> Message-ID: <20031207150247.83973.qmail@web10406.mail.yahoo.com> 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? 2. Thread-urile de tip a/b trebuie sa poata sa execute mai multe operatii in acelasi timp, pe mai multe fisiere? 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? --- 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/ From so@atlantis.cs.pub.ro Sun Dec 7 15:23:53 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sun, 7 Dec 2003 07:23:53 -0800 (PST) Subject: [so] nelamurire privind asincr. In-Reply-To: <20031207150247.83973.qmail@web10406.mail.yahoo.com> Message-ID: <20031207152353.35921.qmail@web41003.mail.yahoo.com> --0-848732975-1070810633=:35469 Content-Type: text/plain; charset=us-ascii 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 --0-848732975-1070810633=:35469 Content-Type: text/html; charset=us-ascii

Toma Monica <moniqqus@yahoo.com> 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 --0-848732975-1070810633=:35469-- From so@atlantis.cs.pub.ro Sun Dec 7 15:47:09 2003 From: so@atlantis.cs.pub.ro (Cristian Zamfir) Date: Sun, 7 Dec 2003 17:47:09 +0200 Subject: [so] nelamurire privind asincr. In-Reply-To: <20031207152353.35921.qmail@web41003.mail.yahoo.com> References: <20031207152353.35921.qmail@web41003.mail.yahoo.com> Message-ID: <200312071747.09291.zamfir@fx.ro> 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 From so@atlantis.cs.pub.ro Sun Dec 7 16:34:39 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sun, 7 Dec 2003 08:34:39 -0800 (PST) Subject: [so] nelamurire privind asincr. In-Reply-To: <200312071747.09291.zamfir@fx.ro> Message-ID: <20031207163439.89061.qmail@web41015.mail.yahoo.com> --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 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

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-- From so@atlantis.cs.pub.ro Sun Dec 7 16:37:18 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sun, 7 Dec 2003 08:37:18 -0800 (PST) Subject: [so] nelamurire privind asincr. In-Reply-To: <20031207163439.89061.qmail@web41015.mail.yahoo.com> Message-ID: <20031207163718.28633.qmail@web41012.mail.yahoo.com> --0-1474136294-1070815038=:27363 Content-Type: text/plain; charset=us-ascii 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? > > 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 > > > --------------------------------- > > 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 --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --0-1474136294-1070815038=:27363 Content-Type: text/html; charset=us-ascii

Fisierele nu au o lungime maxima

George Ciobanu <cdangeorge@yahoo.com> 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 <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
& 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
>
> > ---------------------------------
> > 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

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing --0-1474136294-1070815038=:27363-- From so@atlantis.cs.pub.ro Sun Dec 7 17:17:53 2003 From: so@atlantis.cs.pub.ro (Toma Monica) Date: Sun, 7 Dec 2003 09:17:53 -0800 (PST) Subject: [so] (no subject) Message-ID: <20031207171753.87327.qmail@web10404.mail.yahoo.com> --0-557768052-1070817473=:73707 Content-Type: text/plain; charset=us-ascii se depuncteaza folosirea write / read in loc de send / recv pe sockets ? I dream of finding myself laughing! --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --0-557768052-1070817473=:73707 Content-Type: text/html; charset=us-ascii

se depuncteaza folosirea write / read in loc de send / recv pe sockets ?

I dream of finding myself laughing!

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing --0-557768052-1070817473=:73707-- From so@atlantis.cs.pub.ro Sun Dec 7 17:24:12 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sun, 7 Dec 2003 09:24:12 -0800 (PST) Subject: [so] (no subject) In-Reply-To: <20031207171753.87327.qmail@web10404.mail.yahoo.com> Message-ID: <20031207172412.99412.qmail@web41004.mail.yahoo.com> --0-1983054204-1070817852=:98164 Content-Type: text/plain; charset=us-ascii nu. dar ar fi preferabil sa se utilizeze send/recv Toma Monica wrote: se depuncteaza folosirea write / read in loc de send / recv pe sockets ? I dream of finding myself laughing! --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --0-1983054204-1070817852=:98164 Content-Type: text/html; charset=us-ascii

nu. dar ar fi preferabil sa se utilizeze send/recv

Toma Monica <moniqqus@yahoo.com> wrote:

se depuncteaza folosirea write / read in loc de send / recv pe sockets ?

I dream of finding myself laughing!

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing --0-1983054204-1070817852=:98164-- From so@atlantis.cs.pub.ro Sun Dec 7 19:45:24 2003 From: so@atlantis.cs.pub.ro (Dana Tiba) Date: Sun, 7 Dec 2003 21:45:24 +0200 (EET) Subject: [so] tema3 linux glibc problem Message-ID: <4274.81.196.10.119.1070826324.squirrel@dazoot.ro> Salutare ! M-am lovit de o problema ciudata la tema3 linux dupa ce am facut uz de shared library (monitor.so...) << initial am testat normal ca parte din programul meu >>. Si anume: Pe un RedHat 9.0 up2date cu glibc-2.3.2-27.9.7 tema nu vrea de nici o culoare sa functioneze. Se compileaza OK si la rulare imi da eroare la pthread_cond_wait. [root@bounce-software src]# LD_LIBRARY_PATH="." ./rw 2 3 writer 0>>am intrat in monitor writer 1>>am intrat in monitor writer 1>>waiting for ok to write eroare in functia wait!!! ERROR: No child processes Eroare la o functie ce lucreaza cu variabilele de conditie a monitorului Faza e ca pe un RedHat 7.2 up2date cu glibc-2.2.4-33 tema functioneaza perfect. De asemenea pe un RedHat 7.0 cu glibc-2.2.4-18.7.0.9 la fel tema functioneaza perfect. De asemenea pe SuSe 7.2 cu glibc-2.2.2-67 la fel tema functioneaza perfect. Pentru construirea librariei am folosit exemplul de pe site. eg: gcc -g -Wall -fPIC -c -o monitor.o monitor.c gcc -g -Wall -shared -Wl,-soname,libmonitor.so.0 -o libmonitor.so.0.0 monitor.o -lc -lpthread ln -sf libmonitor.so.0 libmonitor.so /sbin/ldconfig -n . export LD_LIBRARY_PATH="." gcc -g -Wall -o sb sleepingBarbers.o -L. -lpthread -lmonitor gcc -g -Wall -o rw rw.o -L. -lpthread -lmonitor gcc -g -Wall -o dp diningPh.o -L. -lpthread -lmonitor gcc -g -Wall -o bb bb.o -L. -lpthread -lmonitor 2 intrebari: 1) ce poate sa fie in neregula pe RedHat 9.0 ? 2) pe ce sistem se corecteaza tema (ce glibc) ? Multumesc pentru raspuns ! Dana From so@atlantis.cs.pub.ro Sun Dec 7 21:41:42 2003 From: so@atlantis.cs.pub.ro (Toma Monica) Date: Sun, 7 Dec 2003 13:41:42 -0800 (PST) Subject: [so] se poate? Message-ID: <20031207214142.63069.qmail@web10402.mail.yahoo.com> Se pot folosi alte threaduri( sau procese) care sa faca operatia de trmitere. Adica un thread worker poate la randul lui lansa alte thread-uri(procese copil)? ===== I dream of finding myself laughing! __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Sun Dec 7 23:08:11 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Mon, 08 Dec 2003 01:08:11 +0200 Subject: [so] se poate? In-Reply-To: <20031207214142.63069.qmail@web10402.mail.yahoo.com> References: <20031207214142.63069.qmail@web10402.mail.yahoo.com> Message-ID: On Sun, 7 Dec 2003 13:41:42 -0800 (PST), Toma Monica wrote: > Se pot folosi alte threaduri( sau procese) care sa > faca operatia de trmitere. Adica un thread worker > poate la randul lui lansa alte thread-uri(procese copil)? > Cel mai eficient este sa folositi operatii asincrone si atunci cand se trimit datele (da, se pot folosi operatii asincrone si pe socketi). tavi From so@atlantis.cs.pub.ro Mon Dec 8 06:37:07 2003 From: so@atlantis.cs.pub.ro (Ionut Constandache) Date: Sun, 7 Dec 2003 22:37:07 -0800 (PST) Subject: [so] nelamurire privind asincr. In-Reply-To: <20031207163718.28633.qmail@web41012.mail.yahoo.com> Message-ID: <20031208063707.43255.qmail@web41013.mail.yahoo.com> 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? > > > 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/ From so@atlantis.cs.pub.ro Mon Dec 8 06:53:39 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sun, 7 Dec 2003 22:53:39 -0800 (PST) Subject: [so] nelamurire privind asincr. In-Reply-To: <20031208063707.43255.qmail@web41013.mail.yahoo.com> Message-ID: <20031208065339.46057.qmail@web41007.mail.yahoo.com> --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 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? > > > 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

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?
> > > 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-- From so@atlantis.cs.pub.ro Mon Dec 8 07:09:00 2003 From: so@atlantis.cs.pub.ro (Ionut Constandache) Date: Sun, 7 Dec 2003 23:09:00 -0800 (PST) Subject: [so] nelamurire privind asincr. In-Reply-To: <20031208065339.46057.qmail@web41007.mail.yahoo.com> Message-ID: <20031208070900.47869.qmail@web41007.mail.yahoo.com> In concluziei nu prea ai de unde sa sti daca s-a pierdut doar semnalul si in buff ai ce trebuie sau s-a intamplat cu totul altceva (o eroare mai grava si nu ai putut citi/scrie) deci operatia aio trebuie reluata? --- George Ciobanu wrote: > 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 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? > > > > 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 > === message truncated === __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Mon Dec 8 08:07:20 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Mon, 08 Dec 2003 10:07:20 +0200 Subject: [so] nelamurire privind asincr. In-Reply-To: <20031208070900.47869.qmail@web41007.mail.yahoo.com> References: <20031208070900.47869.qmail@web41007.mail.yahoo.com> Message-ID: On Sun, 7 Dec 2003 23:09:00 -0800 (PST), Ionut Constandache wrote: > In concluziei nu prea ai de unde sa sti daca s-a > pierdut doar semnalul si in buff ai ce trebuie sau s-a > intamplat cu totul altceva (o eroare mai grava si nu > ai putut citi/scrie) deci operatia aio trebuie > reluata? > Folositi semnale real-time care nu se pierd (de la SIGRTMIN+4 pana la SIGRTMAX). tavi From so@atlantis.cs.pub.ro Mon Dec 8 09:00:39 2003 From: so@atlantis.cs.pub.ro (Cristian Zamfir) Date: Mon, 8 Dec 2003 11:00:39 +0200 Subject: [so] handler pentru semnale Message-ID: <200312081100.39978.zamfir@fx.ro> 1. Daca folosim un handler pentru semnalele care apar cind se termina o operatie asincrona, nu imi dau seama cum putem sa sincronizam apelarea handlerului cu threadul nostru. Ma gindesc la urmatorul scenariu: Threadul care face cererile aio tocmai modifica ceva in coada de cereri (sa zicem un delete ca urmare a terminarii cu succes a unei alte cereri). Tocmai in mijlocul operatiei se termina o alta operatie asincrona si se executa handler-ul pentru acel semnal, de catre acest thread. Handlerul va face astfel acces nesincronizat la un anumit index din coada (sa zicem ca primeste indexul ca parametru in structura siginfo_t). Pe linga faptul ca indexul ar putea sa nu mai fie consistent, chiar si coada ar putea sa nu mai fie, pentru ca tocmai se executa o operatie delete, si cozile de obicei se fac cu liste inlantuite. Chiar daca sincronizam in interiorul handler-ului accesul la coada, printr-un semafor, indexul, care e primit ca parametru si nu poate sa fie sincronizat poate sa fie inconsistent. 2.Ce se intimpla in cazul in care doua cereri asincrone asociate aceluiasi thread se termina cam in acelasi timp? From so@atlantis.cs.pub.ro Mon Dec 8 09:46:39 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Mon, 08 Dec 2003 11:46:39 +0200 Subject: [so] handler pentru semnale In-Reply-To: <200312081100.39978.zamfir@fx.ro> References: <200312081100.39978.zamfir@fx.ro> Message-ID: On Mon, 8 Dec 2003 11:00:39 +0200, Cristian Zamfir wrote: > 1. Daca folosim un handler pentru semnalele care apar cind se termina o > operatie asincrona, nu imi dau seama cum putem sa sincronizam apelarea > handlerului cu threadul nostru. > Ma gindesc la urmatorul scenariu: Threadul care face cererile aio tocmai > modifica ceva in coada de cereri (sa zicem un delete ca urmare a > terminarii > cu succes a unei alte cereri). Tocmai in mijlocul operatiei se termina o > alta > operatie asincrona si se executa handler-ul pentru acel semnal, de catre > acest thread. Handlerul va face astfel acces nesincronizat la un anumit > index > din coada (sa zicem ca primeste indexul ca parametru in structura > siginfo_t). > Pe linga faptul ca indexul ar putea sa nu mai fie consistent, chiar si > coada > ar putea sa nu mai fie, pentru ca tocmai se executa o operatie delete, si > cozile de obicei se fac cu liste inlantuite. Chiar daca sincronizam in > interiorul handler-ului accesul la coada, printr-un semafor, indexul, > care e > primit ca parametru si nu poate sa fie sincronizat poate sa fie > inconsistent. > Poti sa blochezi semnalele in sectiunea critica. > 2.Ce se intimpla in cazul in care doua cereri asincrone asociate > aceluiasi thread se termina cam in acelasi timp? > Nimic special. Se genereaza doua semnale. Ca sa nu pierzi semnale, e recomandata sa folositi semnale realtime. tavi From so@atlantis.cs.pub.ro Mon Dec 8 09:29:02 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Mon, 8 Dec 2003 01:29:02 -0800 (PST) Subject: [so] handler pentru semnale In-Reply-To: <200312081100.39978.zamfir@fx.ro> Message-ID: <20031208092902.73917.qmail@web41013.mail.yahoo.com> --0-904513596-1070875742=:73598 Content-Type: text/plain; charset=us-ascii Intrebarile tale depind de modul tau de implementarea al problemei si tb rezolvate de tine ;) Cristian Zamfir wrote:1. Daca folosim un handler pentru semnalele care apar cind se termina o operatie asincrona, nu imi dau seama cum putem sa sincronizam apelarea handlerului cu threadul nostru. Ma gindesc la urmatorul scenariu: Threadul care face cererile aio tocmai modifica ceva in coada de cereri (sa zicem un delete ca urmare a terminarii cu succes a unei alte cereri). Tocmai in mijlocul operatiei se termina o alta operatie asincrona si se executa handler-ul pentru acel semnal, de catre acest thread. Handlerul va face astfel acces nesincronizat la un anumit index din coada (sa zicem ca primeste indexul ca parametru in structura siginfo_t). Pe linga faptul ca indexul ar putea sa nu mai fie consistent, chiar si coada ar putea sa nu mai fie, pentru ca tocmai se executa o operatie delete, si cozile de obicei se fac cu liste inlantuite. Chiar daca sincronizam in interiorul handler-ului accesul la coada, printr-un semafor, indexul, care e primit ca parametru si nu poate sa fie sincronizat poate sa fie inconsistent. 2.Ce se intimpla in cazul in care doua cereri asincrone asociate aceluiasi thread se termina cam in acelasi timp? _______________________________________________ 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-904513596-1070875742=:73598 Content-Type: text/html; charset=us-ascii

Intrebarile tale depind de modul tau de implementarea al problemei si tb rezolvate de tine ;)

Cristian Zamfir <zamfir@fx.ro> wrote:

1. Daca folosim un handler pentru semnalele care apar cind se termina o
operatie asincrona, nu imi dau seama cum putem sa sincronizam apelarea
handlerului cu threadul nostru.
Ma gindesc la urmatorul scenariu: Threadul care face cererile aio tocmai
modifica ceva in coada de cereri (sa zicem un delete ca urmare a terminarii
cu succes a unei alte cereri). Tocmai in mijlocul operatiei se termina o alta
operatie asincrona si se executa handler-ul pentru acel semnal, de catre
acest thread. Handlerul va face astfel acces nesincronizat la un anumit index
din coada (sa zicem ca primeste indexul ca parametru in structura siginfo_t).
Pe linga faptul ca indexul ar putea sa nu mai fie consistent, chiar si coada
ar putea sa nu mai fie, pentru ca tocmai se executa o operatie delete, si
cozile de obicei se fac cu liste inlantuite. Chiar daca sincronizam in
interiorul handler-ului accesul la coada, printr-un semafor, indexul, care e
primit ca parametru si nu poate sa fie sincronizat poate sa fie inconsistent.

2.Ce se intimpla in cazul in care doua cereri asincrone asociate aceluiasi
thread se termina cam in acelasi timp?

_______________________________________________
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-904513596-1070875742=:73598-- From so@atlantis.cs.pub.ro Tue Dec 9 00:46:39 2003 From: so@atlantis.cs.pub.ro (Cibu Cristian) Date: Tue, 9 Dec 2003 02:46:39 +0200 Subject: [so] localhost Message-ID: <000d01c3bded$e8077ed0$0200a8c0@smeagol> This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C3BDFE.AB7FAD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable este necesar pt client sa suporte linii de comanda de tipul=20 client localhost .................. etc. in enunt spune: client adresa_server .................. iar localhost nu este o adresa. ------=_NextPart_000_000A_01C3BDFE.AB7FAD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

este necesar pt client sa suporte linii de comanda de tipul

client localhost .................. etc.

in enunt spune: client adresa_server ..................

iar localhost nu este o adresa.

------=_NextPart_000_000A_01C3BDFE.AB7FAD00-- From so@atlantis.cs.pub.ro Tue Dec 9 13:24:08 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Tue, 09 Dec 2003 15:24:08 +0200 Subject: [so] localhost In-Reply-To: <000d01c3bded$e8077ed0$0200a8c0@smeagol> References: <000d01c3bded$e8077ed0$0200a8c0@smeagol> Message-ID: On Tue, 9 Dec 2003 02:46:39 +0200, Cibu Cristian wrote: > este necesar pt client sa suporte linii de comanda de tipul > > client localhost .................. etc. > > in enunt spune: client adresa_server .................. > > iar localhost nu este o adresa. Nu, dar se va aprecia daca implementarea permite si linii de genul specificat de tine. tavi From so@atlantis.cs.pub.ro Tue Dec 9 19:15:17 2003 From: so@atlantis.cs.pub.ro (Cibu Cristian) Date: Tue, 9 Dec 2003 21:15:17 +0200 Subject: [so] parsare Message-ID: <000b01c3be88$c7dd88c0$0200a8c0@smeagol> This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C3BE99.8B475F10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable fiind vorba efectiv de o parsare, putem scurta "rd", "wr" si "ls" la = "r", "w" si "l"? evident cu menionarea acestui fapt in readme. ------=_NextPart_000_0008_01C3BE99.8B475F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

fiind vorba efectiv de o parsare, putem = scurta=20 "rd", "wr" si "ls" la "r", "w" si "l"? evident cu menionarea acestui = fapt in=20 readme.

------=_NextPart_000_0008_01C3BE99.8B475F10-- From so@atlantis.cs.pub.ro Tue Dec 9 19:21:51 2003 From: so@atlantis.cs.pub.ro (Florin Pop) Date: Tue, 9 Dec 2003 21:21:51 +0200 (E. Europe Standard Time) Subject: [so] parsare References: <000b01c3be88$c7dd88c0$0200a8c0@smeagol> Message-ID: <3FD620CF.000008.00784@einstein> --------------Boundary-00=_F47NRN00000000000000 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_F47NMY50000000000000" --------------Boundary-00=_F47NMY50000000000000 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable o idee buna, ca am vazut ca unele programe accepta si comenzi prescurtate= =0D mersi de idee.=0D =0D -------Original Message-------=0D =0D From: so@atlantis.cs.pub.ro=0D Date: 9 decembrie 2003 21:15:28=0D To: grup SO=0D Subject: [so] parsare=0D =0D fiind vorba efectiv de o parsare, putem scurta "rd", "wr" si "ls" la "r",= "w si "l"? evident cu menionarea acestui fapt in readme.=0D =20 --------------Boundary-00=_F47NMY50000000000000 Content-Type: Text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

o idee buna, ca am vazut ca unele programe accepta si comenzi p= rescurtate

mersi de idee.

-------Original Message-------

From: so@atlantis.cs.pub.ro

Date: 9 decembrie = 2003 21:15:28

To: grup SO

Subject: [so] pars= are

fiind vorba efectiv de o parsare, putem = scurta "rd", "wr" si "ls" la "r", "w" si "l"? evident cu menionarea acest= ui fapt in readme.

______________________= ______________________________
<= A href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&lang=3D9">= 3D""

IncrediMail - Email has= finally evolved - = Click Here --------------Boundary-00=_F47NMY50000000000000-- --------------Boundary-00=_F47NRN00000000000000 Content-Type: unknown/unknown; name="IMSTP.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj 1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5 BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs= --------------Boundary-00=_F47NRN00000000000000-- From so@atlantis.cs.pub.ro Tue Dec 9 19:59:20 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Tue, 09 Dec 2003 21:59:20 +0200 Subject: [so] parsare In-Reply-To: <000b01c3be88$c7dd88c0$0200a8c0@smeagol> References: <000b01c3be88$c7dd88c0$0200a8c0@smeagol> Message-ID: On Tue, 9 Dec 2003 21:15:17 +0200, Cibu Cristian wrote: > fiind vorba efectiv de o parsare, putem scurta "rd", "wr" si "ls" la > "r", "w" si "l"? evident cu menionarea acestui fapt in readme. Nu. Parsare?? Sa fim seriosi. In loc sa scrii mailul asta mai bine faceai "parsarea". tavi From so@atlantis.cs.pub.ro Wed Dec 10 08:35:01 2003 From: so@atlantis.cs.pub.ro (Marian Mihailescu) Date: Wed, 10 Dec 2003 10:35:01 +0200 (EET) Subject: [so] [Fwd: Re: legat de tema4 SO] Message-ID: <1105.141.85.0.67.1071045301.squirrel@www.as.ro> ---------------------------- Original Message ---------------------------= - Subject: Re: legat de tema4 SO From: "Octavian Purdila" Date: Tue, December 9, 2003 11:03 pm To: "Marian Mihailescu" -------------------------------------------------------------------------= - On Tue, 9 Dec 2003 23:01:24 +0200, Marian Mihailescu wrote: > Buna ziua. > > Daca se folosesc citiri/scrieri asincrone, > atat din fisier cat si de pe socket (server cu select), de ce e=20 avantajos un > numar de threaduri ? Nu ar merge la fel de bine un singur thread care porneste aio_read(write)-urile ? In cazul folosirii de send/receive sunt de > acord cu motivul acelor threaduri .. dar daca in locul lor se foloseste= =20 tot > aio, isi mai are rostul un numar de threaduri ? > Pentru cazul in care masina este uniprocesor un singur thread e de ajuns.= =20 Pentru cazul in care avem o masina cu mai multe procesoare SI incarcarea e=20 suficient de mare atunci mai multe thread-uri pot mari throughtput-ul si micsora latenta=20 raspunsurilor. tavi ----------------------------------------------------------------------- As.Ro - Cont gratuit de Email si 50MB free webhosting. http://www.as.ro From so@atlantis.cs.pub.ro Wed Dec 10 09:54:54 2003 From: so@atlantis.cs.pub.ro (Toma Monica) Date: Wed, 10 Dec 2003 01:54:54 -0800 (PST) Subject: [so] problema Message-ID: <20031210095454.8330.qmail@web10410.mail.yahoo.com> Buna, am si eu o problema la care pur si simplu nu gasesc explicatie. La thread-urile de tip a la un moment dat, headler-ul semnaleaza faptul ca o operatie care se executa pentru un client s-a terminat, dar in momentul in care testez aio_error imi da EINPROGRESS. Este posibil asa ceva sau sunt toate sansele sa fie o greseala de programare pe undeva? ===== I dream of finding myself laughing! __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Wed Dec 10 23:31:45 2003 From: so@atlantis.cs.pub.ro (Mihai Iancu) Date: Wed, 10 Dec 2003 15:31:45 -0800 (PST) Subject: [so] Socketi In-Reply-To: <200312081100.39978.zamfir@fx.ro> Message-ID: <20031210233145.68373.qmail@web60309.mail.yahoo.com> --0-213309275-1071099105=:66033 Content-Type: text/plain; charset=us-ascii Nu am cautat prea mult sa vad daca pe site la tema sunt si specificatii la socketii folositi pe windows. Cei care folosesc sunt ok? defapt acolo sunt socket si WSASocket, care trebuie folosit? As prefera primul caci este mai esemanator cu cel din Linux --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-213309275-1071099105=:66033 Content-Type: text/html; charset=us-ascii

Nu am cautat prea mult sa vad daca pe site la tema sunt

si specificatii la socketii folositi pe windows.

Cei care folosesc <winsock2.h> sunt ok?

defapt acolo sunt socket si WSASocket, care trebuie folosit?

As prefera primul caci este mai esemanator cu cel din Linux

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-213309275-1071099105=:66033-- From so@atlantis.cs.pub.ro Thu Dec 11 09:17:26 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Thu, 11 Dec 2003 01:17:26 -0800 (PST) Subject: [so] Socketi In-Reply-To: <20031210233145.68373.qmail@web60309.mail.yahoo.com> Message-ID: <20031211091726.99794.qmail@web41011.mail.yahoo.com> --0-394435449-1071134246=:95753 Content-Type: text/plain; charset=us-ascii e ok prima alegere Mihai Iancu wrote: Nu am cautat prea mult sa vad daca pe site la tema sunt si specificatii la socketii folositi pe windows. Cei care folosesc sunt ok? defapt acolo sunt socket si WSASocket, care trebuie folosit? As prefera primul caci este mai esemanator cu cel din Linux --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --0-394435449-1071134246=:95753 Content-Type: text/html; charset=us-ascii

e ok prima alegere

Mihai Iancu <mail2mihai@yahoo.com> wrote:

Nu am cautat prea mult sa vad daca pe site la tema sunt

si specificatii la socketii folositi pe windows.

Cei care folosesc <winsock2.h> sunt ok?

defapt acolo sunt socket si WSASocket, care trebuie folosit?

As prefera primul caci este mai esemanator cu cel din Linux

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing --0-394435449-1071134246=:95753-- From so@atlantis.cs.pub.ro Thu Dec 11 11:05:57 2003 From: so@atlantis.cs.pub.ro (miahi) Date: Thu, 11 Dec 2003 13:05:57 +0200 Subject: [so] get host Message-ID: <20031211120626.592D828C005@atlantis.cs.pub.ro> Am c=E3utat =EEn man dup=E3 gethostbyname (pe care-l folosisem cu succes = anul trecut =EEn temele de PC) =BAi am g=E3sit c=E3 nu e POSIX-compliant, = doar BSD 4.3; tot acolo am g=E3sit =BAi urm=E3toarea not=E3: POSIX 1003.1-2001 marks gethostbyaddr() and gethostbyname() = legacy, and introduces struct hostent *getipnodebyaddr (const void *restrict addr, socklen_t len, int type, int *restrict error_num); struct hostent *getipnodebyname (const char *name, int type, int flags, int *error_num); ok, am zis, s=E3 le caut pe cele noi. [root@home-linux tema4]# man getipnodebyname No manual entry for getipnodebyname [root@home-linux tema4]# man 3 getipnodebyname No entry for getipnodebyname in section 3 of the manual un google(getipnodebyaddr) a g=E3sit ni=BAte pagini de man pentru el, = dar erau de Solaris. Bine=EEn=FEeles c=E3 RH9-le meu habar nu are de = getipnodebyaddr. Cum se face o cerere DNS POSIX-compliant =EEn LINUX? miahi=20 From so@atlantis.cs.pub.ro Thu Dec 11 15:08:17 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Thu, 11 Dec 2003 17:08:17 +0200 Subject: [so] get host In-Reply-To: <20031211120626.592D828C005@atlantis.cs.pub.ro> References: <20031211120626.592D828C005@atlantis.cs.pub.ro> Message-ID: On Thu, 11 Dec 2003 13:05:57 +0200, miahi wrote: man getaddrinfo tavi > Am căutat în man după gethostbyname (pe care-l folosisem cu succes anul > trecut în temele de PC) şi am găsit că nu e POSIX-compliant, doar BSD > 4.3; > tot acolo am găsit şi următoarea notă: > > POSIX 1003.1-2001 marks gethostbyaddr() and gethostbyname() > legacy, > and > introduces > > struct hostent *getipnodebyaddr (const void *restrict addr, > socklen_t len, int type, int *restrict error_num); > > struct hostent *getipnodebyname (const char *name, > int type, int flags, int *error_num); > > ok, am zis, să le caut pe cele noi. > > [root@home-linux tema4]# man getipnodebyname > No manual entry for getipnodebyname > [root@home-linux tema4]# man 3 getipnodebyname > No entry for getipnodebyname in section 3 of the manual > > un google(getipnodebyaddr) a găsit nişte pagini de man pentru el, dar > erau > de Solaris. Bineînţeles că RH9-le meu habar nu are de getipnodebyaddr. > > Cum se face o cerere DNS POSIX-compliant în LINUX? > > miahi > > > _______________________________________________ > so mailing list > so@atlantis.cs.pub.ro > http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From so@atlantis.cs.pub.ro Sat Dec 13 13:43:40 2003 From: so@atlantis.cs.pub.ro (Ruxi Jitianu) Date: Sat, 13 Dec 2003 15:43:40 +0200 Subject: [so] itoa References: <200312081100.39978.zamfir@fx.ro> Message-ID: <3FDB178C.7000207@pcnet.ro> Putem folosi itoa in windows?Nu am gasit una echivalenta in win32 api. merci Ruxandra From so@atlantis.cs.pub.ro Sat Dec 13 14:16:30 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sat, 13 Dec 2003 06:16:30 -0800 (PST) Subject: [so] itoa In-Reply-To: <3FDB178C.7000207@pcnet.ro> Message-ID: <20031213141630.61303.qmail@web41010.mail.yahoo.com> da --- Ruxi Jitianu wrote: > > Putem folosi itoa in windows?Nu am gasit una > echivalenta in win32 api. > > merci > > Ruxandra > > _______________________________________________ > 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. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Fri Dec 12 21:40:46 2003 From: so@atlantis.cs.pub.ro (Lucian Burja) Date: Fri, 12 Dec 2003 23:40:46 +0200 Subject: [so] dictionar Message-ID: <1071265246.15867.5.camel@localhost.localdomain> Am nevoie in tema asta sa folosesc o structura gen dictionar (sa asociez un socket cu o structura unde citesc date corespunzatoare socketului). Exista in bibliotecile linux-ului vreo implementare pentru dictionar? Intre timp am implementat eu dictionarul, dar pe viitor as dori sa folosesc varianta gata implementata daca exista. Multumesc. From so@atlantis.cs.pub.ro Sat Dec 13 15:47:54 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sat, 13 Dec 2003 07:47:54 -0800 (PST) Subject: [so] dictionar In-Reply-To: <1071265246.15867.5.camel@localhost.localdomain> Message-ID: <20031213154754.75899.qmail@web41008.mail.yahoo.com> Daca folosesti C++ si STL, se poate folosi clasa hash_map<...> --- Lucian Burja wrote: > Am nevoie in tema asta sa folosesc o structura gen > dictionar (sa asociez > un socket cu o structura unde citesc date > corespunzatoare socketului). > Exista in bibliotecile linux-ului vreo implementare > pentru dictionar? > Intre timp am implementat eu dictionarul, dar pe > viitor as dori sa > folosesc varianta gata implementata daca exista. > Multumesc. > > _______________________________________________ > 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. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Sat Dec 13 16:43:20 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Sat, 13 Dec 2003 18:43:20 +0200 Subject: [so] teme Message-ID: Ultima data la care puteti trimite teme este 18 ian 2003. Pentru tema 4, penalizarile pe intarzieri se vor face inclusiv pe zilele din vacanta. tavi From so@atlantis.cs.pub.ro Sat Dec 13 16:50:18 2003 From: so@atlantis.cs.pub.ro (Diana Fulger) Date: Sat, 13 Dec 2003 08:50:18 -0800 (PST) Subject: [so] teme In-Reply-To: Message-ID: <20031213165018.27917.qmail@web41012.mail.yahoo.com> Buna seara Asta inseamna pana in sesiune ? Daca nu ma insel, examenul la SO este ultimul, si mie cel putin chiar mi-ar fi folosit timpul pana atunci, intrucat nu am timp fizic pentru a face temele la SO pana in februarie, si nici cea mai mica intentie de a le copia. --- Octavian Purdila wrote: > > Ultima data la care puteti trimite teme este 18 ian > 2003. Pentru tema 4, > penalizarile pe intarzieri > se vor face inclusiv pe zilele din vacanta. > > tavi > _______________________________________________ > 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. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Sat Dec 13 17:30:26 2003 From: so@atlantis.cs.pub.ro (zbant alexandru) Date: Sat, 13 Dec 2003 09:30:26 -0800 (PST) Subject: [so] teme In-Reply-To: Message-ID: <20031213173026.63650.qmail@web42004.mail.yahoo.com> --0-299881722-1071336626=:62511 Content-Type: text/plain; charset=us-ascii nu prea am urmarit foarte mult discutiile de pe forum, dar am o nelamurire, pe site scrrie ca o tema nu poate fi depuctata mai mult de 3 puncte, adica 12zile, dupa ce se intempla? ca nu e specificat nicaieri: nu se mai puncteaza deloc sau se poate trimite dupa o luna tema si poate avea maxim 7pcte din 10 ??? Octavian Purdila wrote: Ultima data la care puteti trimite teme este 18 ian 2003. Pentru tema 4, penalizarile pe intarzieri se vor face inclusiv pe zilele din vacanta. tavi _______________________________________________ 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-299881722-1071336626=:62511 Content-Type: text/html; charset=us-ascii

nu prea am urmarit foarte mult discutiile de pe forum, dar am o nelamurire, pe site scrrie ca o tema nu poate fi depuctata mai mult de 3 puncte, adica 12zile, dupa ce se intempla? ca nu e specificat nicaieri: nu se mai puncteaza deloc sau se poate trimite dupa o luna tema si poate avea maxim 7pcte din 10 ???

Octavian Purdila <tavi@cs.pub.ro> wrote:

Ultima data la care puteti trimite teme este 18 ian 2003. Pentru tema 4,
penalizarile pe intarzieri
se vor face inclusiv pe zilele din vacanta.

tavi
_______________________________________________
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-299881722-1071336626=:62511-- From so@atlantis.cs.pub.ro Sat Dec 13 17:40:53 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sat, 13 Dec 2003 09:40:53 -0800 (PST) Subject: [so] teme In-Reply-To: <20031213173026.63650.qmail@web42004.mail.yahoo.com> Message-ID: <20031213174053.36785.qmail@web41012.mail.yahoo.com> Nota maxima e 7 --- zbant alexandru wrote: > nu prea am urmarit foarte mult discutiile de pe > forum, dar am o nelamurire, pe site scrrie ca o tema > nu poate fi depuctata mai mult de 3 puncte, adica > 12zile, dupa ce se intempla? ca nu e specificat > nicaieri: nu se mai puncteaza deloc sau se poate > trimite dupa o luna tema si poate avea maxim 7pcte > din 10 ??? > > Octavian Purdila wrote: > Ultima data la care puteti trimite teme este 18 ian > 2003. Pentru tema 4, > penalizarile pe intarzieri > se vor face inclusiv pe zilele din vacanta. > > tavi > _______________________________________________ > 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 __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Sun Dec 14 09:17:58 2003 From: so@atlantis.cs.pub.ro (Ruxi Jitianu) Date: Sun, 14 Dec 2003 11:17:58 +0200 Subject: [so] intrebare References: <200312081100.39978.zamfir@fx.ro> Message-ID: <3FDC2AC6.8050004@pcnet.ro> Putem sti, macar asa un pic orientativ, cam care sunt punctajele pentru fiecare dintre situatiile tratate in tema 4? (wr/rd a/b, ls). Multumim! Ruxandra From so@atlantis.cs.pub.ro Sun Dec 14 09:45:32 2003 From: so@atlantis.cs.pub.ro (George Ciobanu) Date: Sun, 14 Dec 2003 01:45:32 -0800 (PST) Subject: [so] intrebare In-Reply-To: <3FDC2AC6.8050004@pcnet.ro> Message-ID: <20031214094532.60774.qmail@web41013.mail.yahoo.com> In genere, distributia punctelor e uniforma ( cu exceptia ls-ului, care va avea un coeficient mai mic) --- Ruxi Jitianu wrote: > Putem sti, macar asa un pic orientativ, cam care > sunt punctajele pentru > fiecare dintre situatiile tratate in tema 4? (wr/rd > a/b, ls). > > Multumim! > > Ruxandra > > _______________________________________________ > 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. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Mon Dec 15 19:29:36 2003 From: so@atlantis.cs.pub.ro (Daniel Cosmin Porumbel) Date: Mon, 15 Dec 2003 11:29:36 -0800 Subject: [so] depanare program Message-ID: <001501c3c341$c6fa7860$42c8100a@16.200.66.p16.pub.ro> This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C3C2FE.B8495040 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0012_01C3C2FE.B8495040" ------=_NextPart_001_0012_01C3C2FE.B8495040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Salut! As avea si eu o intrebare, daca are timp cineva care a mai patit asa = ceva... Am un Segmentation Fault care mi-a aparut doar pe un calculator(din = 3 incercate). -Gdb mi-l localizeaza pe ceva de genul pthread_exit(...) undevea = in libc.so.6. , deci cand se termina un thread. Nici o referinta la o = instructiune scrisa de mine. Apare la procedurile pe care le face el = cand se termina un thread. -Efence nu mi-a gasit nici un fel de buffer overrun/underrun. Cum as putea sa mai depanez? Daca nu gasesc un raspuns, ajung ca domnul din imagine.... toate bune! dany ------=_NextPart_001_0012_01C3C2FE.B8495040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Salut!

As avea si eu o = intrebare,=20 daca are timp cineva care a mai patit asa ceva...

Am un Segmentation=20 Fault care mi-a aparut doar pe un calculator(din 3 = incercate).

= -Gdb mi-l=20 localizeaza pe ceva de genul pthread_exit(...) undevea in libc.so.6. , = deci cand=20 se termina un thread. Nici o referinta la o instructiune scrisa de mine. = Apare=20 la procedurile pe care le face el cand se termina un = thread.

= -Efence nu=20 mi-a gasit nici un fel de buffer overrun/underrun.

Cum as putea sa mai=20 depanez?

Daca nu gasesc un = raspuns, ajung=20 ca domnul din imagine....

toate bune!

dany

------=_NextPart_001_0012_01C3C2FE.B8495040-- ------=_NextPart_000_0011_01C3C2FE.B8495040 Content-Type: image/gif; name="FEELING.GIF" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="FEELING.GIF" R0lGODlhcQBxAPQAAAAAAAAzADMAADMzADMzMzNmAGYzAGZmAGZmZmaZAJlmAMxmAJmZAJnMAMyZ AMzMAMz/AP/MAP//AMzMzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAUK ABQAIf4dR2lmQnVpbGRlciAwLjQgYnkgWXZlcyBQaWd1ZXQAIf8LTkVUU0NBUEUyLjADAQAAACwA AAAAcQBxAAAF/iAljmRpnmiKIgTgEogqz3Rt3zTi7nyM/8CgsNTiGQGEoXLJJPIODAfjwEs2r1hb ETCIRCSS72Ows2bP6NG2+w2DveRXeo5dt73hexxJ7w/tX3hubhF7Zn6INHZvb4GBYYaJkiqLj3eM gZGTm2o7XYSgloSanJKVoaiWpKV9p6KvoausaK6ptplls2m1sL2jubp1nr6Xt79ywUy8qIPEkMDJ QsuvjoO3stFaw7aYjISXr9jZMtONxs6F0OPk2+jn5+LrJOXu9c/I8ib0bg8HAp4MfDWLpS4fhX1g HOzhEUDQo2+p4kXb52XMEU8PuIE7xicfwi9ULu44AAtiuILJ/igmFGlkIx6XHA8FU+mFAUseDJjB VIWyVLluEgzcHGnvJD5WP1++WchSwTtiEv3QHBRy6IFuRe913DSVkIKhLhwYG9grKq12Tx89AAvg YQQeAwKSjdhzF1pnYRgMIBOhqsir1S7uPeAAAtS6WX6G8guAJFO4biWADWAggYOMltIdPeviU0ml mo0EfMwl8lu2I0FplSmsM942FgXn3RM3sxvUO5xWg4P4z91UjkiHdTcItwuSA1cn/v1ZAmPRTwkZ B5CzbG8cKt04GCrX3nQHhzcHUVztQYChA6yhm/6AWGjW2Jk3K/YV7J2HtqZX12iWknxqYazFVnvg 7DSdAJjd/vIeEF19UR9YckWnn2f8XafPf9wIyBZg9bA1gAIPiAUFOgvWQM8YezXwyINgfTLWbTwI ZQRywamnU38HYbjSDu2FcR5uc9kW4GUOqBibC1EkWEg1CpqVVAQaAmDAFzYZJ5ZSWIXywD8sGeCG Aiq+oxwKKlXZWRgy4hYhk6I8oMABCggH1wAPMKBbWuJkt50nEkSJ2lWqqeWAZXtaOYY9Y3biWlpR psdilzwI4ACRUdhpQAFP+DlgIdEFB40OixJXqJSSsZXAdEiOippY6TFToQs+6IiKmVyo2tRzYB2g KVisurRTHntQACoASgYqiqoD4HqRArT++Shbo+XRKRga/rJwHGjnNGCEnEdctVeaqKKWHmFZuhfU CzvkNK2tuN1ZarjiSqDAlTaKolqzANArECG7xvulCwJMwSycCiTwpgIFH5wwwQa/aWdnAekqJICP 2NpdveZ8wW64P3JhwF5ieSOyNQO5oBsD+71GiJlFAAbRLdrCu2lmu0krynFgzFuuTm6EBAOP0a2E YGgyGxFyMRulYnIYYGJrb5s7xLCDAPVozEUYRYukr1vNfYFzBAkssLNpWokwLJ1gjAVlae9mzUOg 0gJXHHUau2yvSVr5kKNrvwZik5cbF/2yyl4sDaXLoSDdpyxbCGCYM2t94vYRcAv00LUSoFwzWbiI tzfb/vhZsl16RE9Hmm3mPmK4zgXaTC2XW13YWYKui+GCGNxeBB4Yj1WukXQAJOBgmHA3Azt882Do tZRwKisS6Vqd6fvOMOpGLuQ4rlHsJYGD1eMX4JaGesbGloqcxPBYqCjoeEdgp8AF39GYyG4x5aXv vchPXV4po7Kl+smbHf684b44mcwhkWEK9PqWnOUpAHzfo4vnZlCLUEiBNlCYX9x2o8BpvSQQX2sV LI6EPEVgpH1mGoC+GkM2N4TvgS+KDIzkUgCnJWo8aAGFXkA0iEJ56TNMEd7YkqY/wIiwGSRUxgl/ hwcZXcw2TNFNUQIDABguMCZXAITc2uDDV+WGgGLS/p9uKIQ7AGoDYIbhWefC9LRzPYGJxnCBEAFA kAkqoXFMjM2dUMeUCLaRGIY7YgQ6VsIlNC6NmLAEl2iUHAkwRV+JA+PNWOjIl+DIN3wrRpEueBwi ZewLfbQc2UC4P075yIyYBEBD8hK+zhxBALoaRPj6J8Oaqa6KoOSNHc9ghygJYC8fciQwn+ApHvgR b0HC2vwiYIAkTmILATBgj9L2sQjl7GptYIrl3oEkKlXBJ0e4koN2YLM4uIwpGPujekKIyuUY8w5V ohojQnInbZKPYvMp1QMvOYcttAUUzPJjX1L2vnyqLRUF00s77eKCVZqGawM8KBAX2s+7tAEoEB0f 9Fbcw89EQBNLXhifQ4qHLS8WchaL2KAkV6rOnQySoh7FyEhrl0g1RrJ+MDVFO9iETHy29KW7HMdH WZrMUc7lhgYJoPiKSrj2ATV2SXUCOW1Z1PY1sKNC3cb0ttkLQkaVgjtoiEhDV9XOQfWrZMqh4kZa Ukd4Fa0mbCgD1dkMrH5Vi4jazVNPClfZqdKGxClRX2+Q0qx44a2DjY9ca4k/uyZWBMu46SmD+lj/ yFWy4HBsZddHxixN9qybVexfmarZ0CrVM7D4pmkNyQMilna1Uq0VJpwJWyXuwACV8gtfa0vYoeyW tzcY1hH0BlwsWOsFxI1GCAAAIfkEBQoAEgAsAAAAAHEAcQCEAAAAADMAMwAAMzMAMzMzZjMAZmYA ZmZmZpkAmWYAmZkAmcwAzJkAzMwAzP8A/8wA//8AzMzMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABf6gJI5kaZ5oih4E4BKHKs90bd/04e58jP/AoLDU4hkBhKFyySTy DAqGwsBLNq9YWxEweDwgkG9jsLNmz+jRtvsNg73kV3qOXbe94XscSe8P7V94bm4Pe2Z+iDR2b2+B gWGGiZIqi493jIGRk5tqO12EoJaEmpySlaGolqSlfaeir6GrrGiuqbaZZbNptbC9o7m6dZ6+l7e/ csFMvKiDxJDAyULLr46Dt7LRWsO2mIyEl6/Y2TLTjcbOhdDj5Nvo5+fi6yTl7vXPyPIm9KDdvs2x 6vJJ2PcoDz9wmHrFi1auH7cHBpghxIVvXUM8Xxjc+iJAwUGD4QIm2zdojC8qLv4GNKg28RifbATv JACwEsxBlBi9EVs4iSCYKAvIGJCikV9Hle9CVizlMwyDIyoFORJjT5VIU+2YfQMzZkdEc9ZyVr33 ctPFjwV2KMgJsmWxnVfp0KMWhsvTAgkdPuAxYO0/hXFpZYUlUUECNwNA6oVwhMuAoQ7gLt012NhH UVtfNTYSoAACBg1CpZucxSdLxS1tbV4dseDosmcaSvyLukGCAY+LBlq9+TDL14euXMTs+p8blEY0 fuHd2EBxssGXmM6MuqCA1R73MjeSPRVPHNOL31kgpQFoiMxDb08uGba0yvbCNEjbfDve9Txq9gKu ZBntNoQwsAd+jWlHYHeE8f4XxDTiGQRBA8gRuFkDEgIgQGjEKAgefDpJ1MB1Fa42k4QKfOKPhjUw +J8bCoTIXIvbDZCAeRBAgQ6K7KQkFihj4LaAKE/hNwCIzAW5A31PWFJIWBJ9J8IitxhJ0yNSMtcF jMxBABpoHgnIQxQYQlLNRt9VkiCFnhASgJC7MYeXG16uhtcXCfz4DnQpnJLKF1gC8OZr24UZYWNa QmHAgJvh1oBhSeUhDiCWPYBmSmH0+SIogz6hwKQEgmbinThC6YyWfC0XogC4jdhbleutlFhVGuqg oz1SJqaqi8wZwCl+GiWmVYJ7+LBNow8sUCqu+CVg6Xq9TuSWoztIIOuU3P7wU6WMyK4HRYhrvTrW gzuw4IJzGyVkLA9IridjAghkq26NuhH7BX1bIHgnqwT6Wpe7VkKQgHJMEjfIsvG6gy+bbozYUQIG KNswuwkw7HDECEQMhcRTjNgXRPo5SBeVR6z1XC+7IrtmSrhFZROATHbIGAC+KWDviYRgWcRXp9my LL88KKdkZhONC8a/iwn8BUow7ADws208dSGgPNe0YjOiuOBbnTsa7cakMVRmzFOv8pzcVpESIjS8 Kzb4mgjTInXaKxR+IjYPByWIigsiQ/j2yqgF24mOtHXTIl4HZzvbz5rB7BQC/731oCxrdHxHQWCb OjcAal8Gyrh8+nYORf7uPcnhN3GTFSKiLlBntyV4hzGjOw8SGd3fXIQm2tYuiIF6em2gnjnimwNA rrK/flPmDgLs+I0LBTScKW8CuETp74Hve1iNknschgOyK+JJZA6R6uLTbqTLBfBaG+QCAkcvbUv3 KSKPWjOGZTwFI8IbZxW6mlOditWus1MvuBcYFETuMm95gGHikADHPQJRn0LgYqzWvsM56QSuKA4D bnOyx7SoNUaDoOoaFIr1QSJgXLmgAT1hO4SoagBLE96zIGC+6yGkccFrIAQ+UR0V5mkY4ilRFBhh pDnZAlGtSZvmtNOaV4WiK6T5wRYEAD6BgYI+fmkQorI4P62Zyi+f0v5DATfkgujtZxBFvB3oAEi9 vWnHN04MBBRD1x8Wru4eAvRG+YzAPiU6zg1nw1wzfHgDPVEDip7DiBh7pjo16oSNvgrEyejYhC0E wI1vABG59LdDI3SsbIp8GbniSEggiIoQi5JCHIYCmraYDgDuK1sz8MaRPExydrGxIwQUYL6UQEVX jEBUHtniyEdAEk+JAAQPUJWqHaaMBzp8ZSzH9LuzFWCOuJzDGhBwHamBoQAbs4m/zrdHurVxgopT YBWYcoSlqQokq1wjAPJyxsQ1cYxy8eQjYJQ8RqDkep3kAVtoVjWY4YgTWxDkIyIWJi9AJDud6w6x 9DKFEuETEZbEzPRH/OdHvmESmQwZTD37kaFu7KmUfsioEhs50SZdFKEcuqE/PieaWwpEdGVsKHUi VZDDvQGlZhkdJs94uAfY9Kbz2MEl+wc7poEUqbQLoxf31EU1vXQcKnUWqIoG1JF47YYP0ctRofpD Fyx1cnWjata6itV2pOat/RgrWXMEgEs6tR5szQekqFc0uc7Ve2Ytpv+UQsm/UkJ+v3OLXw0bP7NK ZaOEzSZj6RpGlkryqpPVh1LviJG8ZtY/rllnZuvo2GIedLSm/CogMYvaw5Y2sq0VDgt55NnYOuFI UeClaG0rW95IlrdBmNYRfADcM4jrBcTNRggAACH5BAUKABEALAAAAABxAHEAhAAAAAAzADMAADMz ADMzM2YzAGZmAGZmZmaZAJlmAJmZAJnMAMyZAMzMAP/MAP//AMzMzAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX+YCSOZGmeaIoeBOAShyrPdG3f9OHufIz/wKCw 1OIZAYShcskk8gwKhsLASzavWFsRMHA4Ho9vY7CzZs/o0bb7DYO95Fd6jl23veF7HEnvD+1feG5u Dntmfog0dm9vgYFhhomSKouPd4yBkZObajtdhKCWhJqckpWhqJakpX2noq+hq6xorqm2mWWzabWw vaO5unWevpe3v3LBTLyog8SQwMlCy6+Og7ey0VrDtpiMhJev2Nky043GzoXQ4+Tb6Ofn4usk5e6W CwAKvfHyywrM7wUAGLimTp6IZQ8SDBjQoJmoZm4YwCu4bpoCFwPeQWwzERm/dqikCExwrtoddPv+ WNELM1AjuHe4PCZbefJfPTAEZc6iCTHUS2I/j/HRxdNnTylQfG1MlbIVyIffQEW9aKQAzJxDN5XL s1QqlSMuGtwMR9EpxrGYLFEF6yIMjwH+6jUVdvYqLEJsnzwAuxABg4ZYD83h+UrBAAEYGSDIy2Mv Y4wKFDS0lE7nGYRBv3w10iDgYwAMPhsZ+OiZ5SvTSpdmsMcIa9FrRQMgabJyVrpc8Nzl2iYB4zGw Ze8woPrNXByLbhVzEBvs68+hheMLjLqdUkHMPzfYzNiBdNDEjs84ZYxrdMZ5Plv9Ppn6n2H17gR4 LBYMd7ANv+freBv5Nm5SwQFdHrYdkY930g3+IBF/gtUACDe6MdIcW3G94ZkR+zkmnGER6lMWJf/F 55ZoxFnDgAEDFADXJaINkEADEkEBk3gRPAjLGAtVyJJsGdXEUShVHVHiKHJ96ERdt5wHmhsTooed OaL89Zc/z7kQRX1ffDKjkQfBB2EDPFiVpXQLdmhMlWCV6EACC0TYjSpGJtfLF7Fl9ICSsL2USgMJ GIDiZws1oABJUbl3ZG7OhAGmJ6YJp2ZUgSyQwF/fgTaGXY0KJmd5SnaxqHQCwLjAlCf+uYNflYr1 yVik6HDWTUpa1Vpe98k2aaUS9YipbT6ECNM9w9ha62cGfCpcrqXZtUcErgKAZYDd3GnEAMP+gpVA k48Z4Jt+hTgklS2fsuDCo5Rt5ACwngiHQCEpVvpdRgZINOebbni2hT8AuomndISC4W6Caz6b6CMT MpDZT8Z+J+YX2wowRQIJIAAxFH1GPPGg2j5scZ+QPRAvMz9ZkvB0Zvqy77/zYaQiQxy1jJPL3ljJ cJvQmgnKWkUMWQ+6/z4mb7nYlewYbR/fRcxXMOzQnjuhhVpgzzzUV2hNqYwbRhT0QvhAuBE89fK3 DoDZI9RsyWuNbsuB4gKhSb05r20iNMuQt6p9EdonZIOVSto2u7Bu2AkYDfIePtRoXdZ0AmDVyWSD 7Lgla4ehmNYiy7KG1NQompuGee+Q+UP+sIxLZ+B7ByjOVnZz0Wils7ZV3OdAkhwZ5Yruc/nji4rR On1ttP7642oLpJnAXdnW4KGrQjpiAdpWy5YAQmGkvOCQzxbGpKUHAtxpJtz+O+OfOV3vtMXRK7Tf M7u8HI21hDKoxuu+IZA3b84qJvB6fhG5A8X+rjuXJ/Aeb6B1NYXsb3oPmJWdYJe/EZWoaAOMSX8c BJJUSGEP1LoIuaKlwKAYxSRDg0TNtoYY7inCE4BJVnYSgxfSIO5C+wPdCAcRuQRmhkYosBFXHmCY Fz3iPAtjxqxaAg7q4WV+3TLT9iYIBAFSTRSeyRA1ZkWbAWYvePvREpxM+ANX8E1aLrj+nxCNQKgG +s+BYRDj/7jYRBS+ThRxqBAsZhU/BppvaPozCQ61gSQ3PWJ7ZWSKa2jnPyuJ8A5VGAwKR+iFEhLH FzB0lhGB5gbRJbARe+ziU7QnGQU4UkpnW92S7FhI6xUiEClj4mV4EAgFRBIjR6DWs2ZFMxnaspLC u6TxTDEMYwlgIcxL4EJa48Knme2WtpTZAwrQgBKqUpEuCIABpQYGFWUIDL5hQzWNEEpkDtBqK2Tj Lo5wzM3wJg4unBUjlwKO/WWyOlEjmAsEcImvVHFWlMxnN0T3TtwAQBTXmowjZNTKaxUPf2qJVyqP x4ktBCBk0fLmdWa4y2zo8G34u+LvGxf6kR24RKOEjAUAVbID6A0so+q7owM4apAuedQd68yMIMUZ jE1NVGg4DQVLWzqPHTxUhR+845ZoalGvAa88oFvpSDsKgIciMKhum+kzeerSzUH0jRHV6VJ56lCh UfSMFaXqeCqIVbASYqdiHWs0QehHBG5xqmntnq/MqFK0xvWEa/WfWcN6Vz5aVaJaJWpfD+XUoHpI sINFnpvYedatJjaAjfHRYeH6WHa8yhs/sWtlNfnSIgqFoZu9wRZMWj6lIja0KeiqufqJWrliRGBL BG1rOTuuKEwhkbOFZ15km1sgNOsIhestFsT1guBGIwQAIfkEBQoAFAAsAAAAAHEAcQAABf4gJY5k aZ5oiiIE4BKIKs90bd804u58jP/AoLDU4hkBhKFyySTyDgwH48BLNq9YWxEwiEQkku9jsLNmz+jR tvsNg73kV3qOXbe94XscSe8P7V94bm4Re2Z+iDR2b2+BgWGGiZIqi493jIGRk5tqO12EoJaEmpyS laGolqSlfaeir6GrrGiuqbaZZbNptbC9o7m6dZ6+l7e/csFMvKiDxJDAyULLr46Dt7LRWsO2mIyE l6/Y2TLTjcbOhdDj5Nvo5+fi6yTl7vXPyPIm9G4PBwKeDHw1i6UuH4V9YBzs4RFA0KNvqeJF2+dl zBFPD7iBO8YnH8IvVC7uOAALYriCyf4oJhRpZCMelxwPBVPphQFLHgyYwVSFslS5bhIM3Bxp7yQ+ Vj9fvlnIUsE7YhL90BwUcuiBbkXvddw0lZCCoS4cGBvYKyqtdk8fPQAL4GEEHgMCko3YcxdaZ2EY DCAToarIq9Uu7j3gAALUull+hvILgCRTuG4lgA1gIIGDjJbSHT3r4lNJpZqNBHzMJfJbtiNBaZUp rDPeNhYF590TN7Mb1DucVoOD+M/dVI5Ih3U3CLcLkgNXJ/79WQJj0U8JGQeQs2xvHCrdOBgq1950 B4c3B1Fc7UGAoQOsoZv+gFho1tiZNyv2Feydh7amV9dolpJ8amGsxVZ74Ow0nQCY3f7yHhBdfVEf WHJFp59n/F2nz3/cCMgWYPWwNYACD4gFBToL1kDPGHs18MiDYH0y1m08CGUEcsGpp1N/B2G40g7t hXEebnPZFuBlDqgYmwtRJFhINQqalVQEGgJgwBc2GSeWUliF8sA/LBnghgIqvqMcCipV2VkYMuIW IZOiPKDAAQoIB9cADzCgW1riZLedJxJEidpVqqnlgGV7WjmGPWN24lpaUabHYpc8COAAkVHYaUAB T/g5YCHRBQeNDosSV6iUkrGVwHRIjoqaWOkxU6ELPuiIiplcqNrUc2AdoClYrLq0Ux57UAAqAEoG KoqqA+B6kQK0/vkoW6Pl0SkYGv6ycBxo5zRghJxHXLVXmqiilh5hWboX1As75DStrbjdWWq44kqg wJU2iqJaswDQKxAhu8b7pQsCTMEsnAok8KYCBR+cMMEGv2lnZwHpKiSAj9jaXb3mfMFuuD9yYcBe YnkjsjUDuaAbA/u9RoiZRQAG0S3awrtpZrtJK8pxYMxbrk5uhAQDj9GthGBoMhsRcjEbpWJyGGBi a2+bO8SwgwD1aMxFGEWLpK9bzX2BcwQJLLCzaVqJMCydYIwFZWnvZs1DoNICVxx1Grtsr0la+ZCj a78GYpOXGxf9sspeLA2ly6Eg3acsWwhgmDNrfeL2EXAL9NC1EqBcM1m4iLc32/74WbJdekRPR5pt 5j5iuM4F2kwtl1td2FmCrovhghjcXgQeGI9VrpF0ACTgYJhwNwM7fPNg6LWUcCorEulanen7zjDq Ri7kOK5R7CWBg9XjF+CWhnrGxpaKnMTwWKgo6HhHYKfABd/RmMhuMeWl773IT11eKaOypfrJmx3+ vOG+OJnMIZFhCvT6lpzlKQB836OL52ZQi1BIgTZQmF/cdqPAab0kEF9rFSyOhDxFYKR9ZhqAvhpD NjeE74EvigyM5FIApyVqPGgBhV5ANIhCeekzTBHe2JKmP8CIsBkkVMYJf4cHGV3MNkzRTVECAwAY LjAmVwCE3Nrgw1flhoBi0v6fbiiEOwBqA2CG4VnnwvS0cz2BicZwgRABQJAJKqFxTIzNnVDHlAi2 kRiGO2IEOlbCJTQujZiwBJdolBwJMEVfiQPjzVjoyJfgyDd8K0aRLngcImXsC320HNlAuD9O+ciM mARAQ/ISvs4cQQC6GkT4+ifDmqmuiqDkjR3PYIcoCWAvH3IkMJ/gKR74EW9Bwtr8ImCAJE5iCwEw YI/S9rEI5exqbWCK5d6BJCpVwSdHuJKDdmCzOLiMKRj7o3pCiMrlGPMOVaIaI0JyJ22Sj2LzKdUD LzmHLbQFFMzyY19S9r58qi0VBdNLO+3iglWahmsDPCgQF9rPu7QBKBAdH/RW3MPPREATS14Yn0OK hy0vFnIWi9igJFeqzp0MkqIexchIa5dINUayfjA1RTvYhEx8tvSluxzHR1mazFHO5YYGCaD4ikq4 9gE1dkl1AjltWdT2NbCjQt3G9LbZC0JGlYI7aIhIQ1fVzkH1q2TKoeJGWlJHeBWtJmwoA9XZDKx+ VYuI2s1TTwpX2anShsQpUV9vkNKseOGtg42PXGuJP7smVgTLuOkpg/pY/8hVsuBwbGXXR8YsTfas m1XsX5mq2dAq1TOw+KZpDckDIpZ2tVKtFSacCVsl7sAAlfILX2tL2KHslrc3GNYR9AZcLFjrBcSN RggAADs= ------=_NextPart_000_0011_01C3C2FE.B8495040-- From so@atlantis.cs.pub.ro Mon Dec 15 11:46:34 2003 From: so@atlantis.cs.pub.ro (Adrian Stanciu) Date: Mon, 15 Dec 2003 13:46:34 +0200 Subject: [so] depanare program In-Reply-To: <001501c3c341$c6fa7860$42c8100a@16.200.66.p16.pub.ro> References: <001501c3c341$c6fa7860$42c8100a@16.200.66.p16.pub.ro> Message-ID: <3FDD9F1A.3060202@romus.ro> Daniel Cosmin Porumbel wrote: > Salut! > > As avea si eu o intrebare, daca are timp cineva care a mai patit > asa ceva... > Am un Segmentation Fault care mi-a aparut doar pe un > calculator(din 3 incercate). > -Gdb mi-l localizeaza pe ceva de genul pthread_exit(...) > undevea in libc.so.6. , deci cand se termina un thread. Nici o > referinta la o instructiune scrisa de mine. Apare la procedurile pe > care le face el cand se termina un thread. Ptreat fiind biblioteca user space, este foarte posibil sa te bagi peste datele ei. Si cand apelezi pthread_exit biblioteca da eroare. Exact efectul asta l-am intalnit eu personal si e posibil sa fie aceeasi problema si la tine. Mai verifica inca odata programul cu atentie. --sadyc From so@atlantis.cs.pub.ro Mon Dec 15 15:25:49 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Mon, 15 Dec 2003 17:25:49 +0200 Subject: [so] depanare program References: <001501c3c341$c6fa7860$42c8100a@16.200.66.p16.pub.ro> Message-ID: <002c01c3c320$65ed5bd0$750c6150@ioana> This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C3C330.7B4D83F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Buna, Eu am avut urmatoarea problema, si poate tot asta este si cauza = problemei tale : pe Red Hat 9.0 cu glibc 2.3.2-11.9 (cel cu care vine rh9) dupa ce se = termina o operatie asincrona si primeam semnalul de terminare, daca = vroiam sa astept un alt semnal cu pause sau sigwait de ex, cand faceam = acel pause/sigwait obtineam un segmentation fault. De exemplu in = sample-ul trimis pe lista (cel cu aio_sigevent) daca la sfarsit dupa = pause mai puneam un al 2-lea pause, la acesta obtineam segm fault. Pe = Red Hat 8 sau alt RH mai vechi nu se intampla. Pe RH9 trebuie facut = update la glibc (la 2.3.2-27.9.7) si se rezolva problema. Segm fault respectiv (din ce am vazut cu gdb) se obtinea intr-un fir = (altul decat cele create de mine) care era creat pt. a face operatia = asincrona. ----- Original Message -----=20 From: Daniel Cosmin Porumbel=20 To: so@atlantis.cs.pub.ro=20 Sent: Monday, December 15, 2003 9:29 PM Subject: [so] depanare program Salut! As avea si eu o intrebare, daca are timp cineva care a mai patit = asa ceva... Am un Segmentation Fault care mi-a aparut doar pe un = calculator(din 3 incercate). -Gdb mi-l localizeaza pe ceva de genul pthread_exit(...) = undevea in libc.so.6. , deci cand se termina un thread. Nici o referinta = la o instructiune scrisa de mine. Apare la procedurile pe care le face = el cand se termina un thread. -Efence nu mi-a gasit nici un fel de buffer overrun/underrun. Cum as putea sa mai depanez? Daca nu gasesc un raspuns, ajung ca domnul din imagine.... toate bune! dany ------=_NextPart_000_0015_01C3C330.7B4D83F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Buna,

Eu am avut urmatoarea problema, si = poate tot asta=20 este si cauza problemei tale :

pe Red Hat 9.0 cu glibc 2.3.2-11.9 (cel = cu care=20 vine rh9) dupa ce se termina o operatie asincrona si primeam semnalul de = terminare, daca vroiam sa astept un alt semnal cu pause sau sigwait de = ex, cand=20 faceam acel pause/sigwait obtineam un segmentation fault. De exemplu in=20 sample-ul trimis pe lista (cel cu aio_sigevent) daca la sfarsit dupa = pause mai=20 puneam un al 2-lea pause, la acesta obtineam segm fault. Pe Red Hat 8 = sau alt RH=20 mai vechi nu se intampla. Pe RH9 trebuie facut update la glibc (la = 2.3.2-27.9.7)=20 si se rezolva problema.

Segm fault respectiv (din ce am vazut = cu gdb) se=20 obtinea intr-un fir (altul decat cele create de mine) care era creat pt. = a face=20 operatia asincrona.

----- Original Message -----
From:=20 Daniel = Cosmin=20 Porumbel
To: so@atlantis.cs.pub.ro

Sent: Monday, December 15, 2003 = 9:29=20 PM

Subject: [so] depanare = program

Salut!

    As avea si eu = o=20 intrebare, daca are timp cineva care a mai patit asa = ceva...

    Am un Segmentation = Fault care mi-a aparut doar pe un calculator(din 3=20 incercate).

        = -Gdb mi-l=20 localizeaza pe ceva de genul pthread_exit(...) undevea in libc.so.6. , = deci=20 cand se termina un thread. Nici o referinta la o instructiune scrisa = de mine.=20 Apare la procedurile pe care le face el cand se termina un=20 thread.

        = -Efence nu=20 mi-a gasit nici un fel de buffer overrun/underrun.

    Cum as putea sa = mai=20 depanez?

    Daca nu gasesc un = raspuns,=20 ajung ca domnul din imagine....

toate bune!

dany

------=_NextPart_000_0015_01C3C330.7B4D83F0-- From so@atlantis.cs.pub.ro Tue Dec 16 19:00:51 2003 From: so@atlantis.cs.pub.ro (Mihai Iancu) Date: Tue, 16 Dec 2003 11:00:51 -0800 (PST) Subject: [so] Tema 4 In-Reply-To: <001501c3c341$c6fa7860$42c8100a@16.200.66.p16.pub.ro> Message-ID: <20031216190051.32386.qmail@web60305.mail.yahoo.com> --0-929982488-1071601251=:31927 Content-Type: text/plain; charset=us-ascii Pe tema de windows am folosit pt listare ls, e ok? Adica cel care corecteaza il are? (George ...?) --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard --0-929982488-1071601251=:31927 Content-Type: text/html; charset=us-ascii

Pe tema de windows am folosit pt listare ls, e ok? Adica cel care corecteaza il are?

(George ...?)

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard --0-929982488-1071601251=:31927-- From so@atlantis.cs.pub.ro Wed Dec 17 03:00:30 2003 From: so@atlantis.cs.pub.ro (Cosmin Arad) Date: Tue, 16 Dec 2003 19:00:30 -0800 (PST) Subject: [so] clarificari mmap Message-ID: <20031217030030.99527.qmail@web60505.mail.yahoo.com> Salut, Fata de grupa 341CA am ramas dator cu 2 explicatii de la laboratorul de mmap. Pentru ca nu ne mai intalnim saptamana asta sa le discutam si pentru ca poate mai au si altii aceleasi nelamuriri am trimis aici lamuririle pentru toata lumea: 1. Am vazut ca daca mapam o pagina WriteOnly (WO) si incercam sa citim din ea primim un SIGSEGV. Am mai vazut ca daca incercam sa scriem ceva si apoi sa citim nu primim SIGSEGV. Asadar, desi pagina e WO se poate citi din ea. Problema este ca arhitectura x86 nu ofera decat 2 biti de protectie pentru o pagina. Unul pentru read-only/read-write si unul pentru user-mode/kernel-mode. Vezi http://www.intel.com/design/pentium4/manuals/24547212.pdf, pagina 137. Stim ca intrarile din tabela de pagini, cele mai des folosite sunt tinute in TLB. Cand procesorul are de translatat o adresa virtuala intr-o adresa fizica va cauta pagina din care face parte adresa virtuala in TLB. Daca o gaseste, face translatarea dar daca nu genereaza o exceptie (page fault) care este tratata de sistemul de operare prin intermediul unui page fault handler. Procesorul genereaza un page fault in mai multe situatii, nu doar aceasta, insa in acest caz handlerul se va ocupa de gasirea paginii respective in tabela de pagini, verificarea protectiei, si daca totul e ok, "introducerea" ei in TLB. Vezi http://lxr.linux.no/source/Documentation/cachetlb.txt. Asadar in page fault handler se pot verifica bitii de protectie read, write, execute si se poate actiona in consecinta, de exemplu prin trimiterea unui SIGSEGV procesului care a facut accesul in cazul in care pagina era protejata impotriva accesului respectiv. La primul acces, pagina nefiind in TLB se va apela handlerul care va verifica corect bitii de protectie. La al doilea acces pagina este deja in TLB si la translatare procesorul va verifica bitii de protectie disponibili in TLB. Cum pe x86 avem read-only sau read-write, un read este permis oricum, de unde rezulta comportamentul pe care l-am observat la laborator. Daca dupa accesul de scriere invalidam TLB-ul, cand facem citirea pagina nu este in TLB se va apela din nou page fault handlerul si bitii de protectie vor fi verificati, se va observa ca pagina e WO si procesul va primi un SIGSEGV. Pentru exemplificare iata un exemplu de test: #include #include int main(void) { char *ptr, c; unsigned int tmpreg; ptr = mmap(0, 100, PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, 0, 0); *ptr = 'a'; // scriere /* tlb flush */ __asm__ __volatile__ ( "movl %%cr3, %0; \n" "movl %0, %%cr3; \n" : "=r" (tmpreg) :: "memory"); c = *ptr; // citire printf("Caracter: '%c'=%d.\n", c, c); munmap(ptr, 100); return 0; } Daca comentam intructiunea de flush, nu se primeste SIGSEGV. Daca o lasam asa se primeste la citire. 2. De ce daca faceam o mapare privata a unui fisier in memorie si faceam modificari acestea nu erau scrise in fisier. Este normal sa fie asa pentru ca am interpretat gresit flagul MAP_PRIVATE. O mapare MAP_PRIVATE presupune ca maparea este privata procesului respectiv si modificarile pe care le face el nu sunt vizibile in alta parte, deci nici in fisier. O mapare MAP_SHARED nu presupune neaparat ca aceeasi zona e partajata cu alte procese, ci faptul ca modificarile facute de un proces sunt vizibile in alta parte deci si in fisier. Din acest motiv "nu mergea cu MAP_PRIVATE" :) Sarbatori fericite! Cosmin PS La challenge nu au raspuns decat 4 oameni: Boita Ioana (341), Murgan Mihai (342), Hagiescu Andrei si Soptica Irina (346). Va incurajez sa va uitati inca pe semaforul ala. Provocarea e inca deschisa. __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree From so@atlantis.cs.pub.ro Wed Dec 17 03:22:14 2003 From: so@atlantis.cs.pub.ro (Cosmin Arad) Date: Tue, 16 Dec 2003 19:22:14 -0800 (PST) Subject: [so] clarificari mmap In-Reply-To: <20031217030030.99527.qmail@web60505.mail.yahoo.com> Message-ID: <20031217032214.35556.qmail@web60510.mail.yahoo.com> --- Cosmin Arad wrote: > Daca o gaseste, face translatarea > dar daca nu genereaza o exceptie (page fault) care > este tratata de sistemul de operare > prin intermediul unui page fault handler. Procesorul > genereaza un page fault in > mai multe situatii, nu doar aceasta, insa in acest > caz > handlerul se va ocupa de > gasirea paginii respective in tabela de pagini, > verificarea protectiei, si daca totul > e ok, "introducerea" ei in TLB. Dupa tratarea exceptiei, deci dupa rularea page fault handler-ului, executia se reia cu instructiunea care a generat exceptia, pentru ca acum pagina ceruta este in TLB si totul continua la fel ca si cum nimic nu s-ar fi intamplat. Ar fi fost absurd sa se reia executia cu urmatoarea instructiune pentru ca s-ar fi pierdut efectul instructiunii care a generat faultul. Asa se explica si faptul ca daca executam o instructiune faulty si tratam semnalul SIGSEGV fara sa modificam bitii de protectie ai paginii, semnalul venea la nesfarsit. Venea pentru ca instructiunea faulty se executa din nou, exceptia aparea iar, page fault handlerul se executa din nou si trimitea SIGSEGV procesului. Dupa executia page fault handlerului instructiunea faulty era executata din nou si asa mai departe. Din nou Sarbatori fericite! Cosmin __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree From so@atlantis.cs.pub.ro Wed Dec 17 10:14:29 2003 From: so@atlantis.cs.pub.ro (Dorin Moise) Date: Wed, 17 Dec 2003 12:14:29 +0200 Subject: [so] note teme Message-ID: <200312171014.hBHAEUKH019956@k.k.ro> As vrea sa stiu daca pana la inceputul vacantei toate grupele vor avea nota pe tema 1. (adica pana vineri seara). Nu inteleg de ce dureaza atat. Unii si-au primit notele pe prima tema de aproape o luna... Altii la anu'? ----------------------------------------- .dorin moise Sentimente.ro - www.sentimente.ro Peste 50.000 de prieteni te asteapta! From so@atlantis.cs.pub.ro Wed Dec 17 18:20:38 2003 From: so@atlantis.cs.pub.ro (Ion Petrescu) Date: Wed, 17 Dec 2003 20:20:38 +0200 Subject: [so] note teme - La multi ani! In-Reply-To: <200312171014.hBHAEUKH019956@k.k.ro> References: <200312171014.hBHAEUKH019956@k.k.ro> Message-ID: <176131840065.20031217202038@rdsnet.ro> Nu am nici o calitate sa iti raspund, insa, sunt sigur ca au si ei lucruri mai bune de facut acum la sfarsit de an. Dealtfel, odata cu publicarea baremului ai putea sa iti dai seama, cu o precizie foarte mare, ce nota o sa iei. Profit de ocazie sa urez "Sarbatori fericite!" co-listasilor. Wednesday, December 17, 2003, 12:14:29 PM, you wrote: DM> As vrea sa stiu daca pana la inceputul vacantei toate grupele vor avea nota DM> pe tema 1. (adica pana vineri seara). Nu inteleg de ce dureaza atat. Unii DM> si-au primit notele pe prima tema de aproape o luna... Altii la anu'? DM> ----------------------------------------- DM> .dorin moise -- Best regards, Ion mailto:pion@rdsnet.ro From so@atlantis.cs.pub.ro Wed Dec 17 20:23:45 2003 From: so@atlantis.cs.pub.ro (Andrei Hagiescu) Date: Wed, 17 Dec 2003 22:23:45 +0200 Subject: [so] note teme - La multi ani! References: <200312171014.hBHAEUKH019956@k.k.ro> <176131840065.20031217202038@rdsnet.ro> Message-ID: <005b01c3c4db$ac82c8c0$6400a8c0@andrei> Si noi poate avem lucruri mai bune de facut dar atata timp cat SI IN VACANTA va curge timpul pentru tema 4, putem presupune ca scoala continua pentru toti :) (atat pentru intrebari, cat si pentru raspunsuri) ----- Original Message ----- From: "Ion Petrescu" To: "Dorin Moise" Sent: Wednesday, 17 December, 2003 20:20 PM Subject: Re: [so] note teme - La multi ani! > > Nu am nici o calitate sa iti raspund, insa, sunt sigur ca > au si ei lucruri mai bune de facut acum la sfarsit de an. > > Dealtfel, odata cu publicarea baremului ai putea sa iti dai seama, cu > o precizie foarte mare, ce nota o sa iei. > > > Profit de ocazie sa urez "Sarbatori fericite!" co-listasilor. > > > > Wednesday, December 17, 2003, 12:14:29 PM, you wrote: > DM> As vrea sa stiu daca pana la inceputul vacantei toate grupele vor avea nota > DM> pe tema 1. (adica pana vineri seara). Nu inteleg de ce dureaza atat. Unii > DM> si-au primit notele pe prima tema de aproape o luna... Altii la anu'? > DM> ----------------------------------------- > DM> .dorin moise > > -- > Best regards, > Ion mailto:pion@rdsnet.ro > > _______________________________________________ > so mailing list > so@atlantis.cs.pub.ro > http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so > > > --------------------------------------------------------------- > Acasa.ro vine cu albumele, tu vino doar cu pozele ;) > http://poze.acasa.ro/ > > > From so@atlantis.cs.pub.ro Fri Dec 19 17:58:14 2003 From: so@atlantis.cs.pub.ro (Diana Fulger) Date: Fri, 19 Dec 2003 09:58:14 -0800 (PST) Subject: [so] (no subject) Message-ID: <20031219175814.78990.qmail@web41013.mail.yahoo.com> Sub riscul previzibilitatii, va urez sarbatori fericite. __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Fri Dec 19 18:58:21 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Fri, 19 Dec 2003 20:58:21 +0200 Subject: [so] tema5 Message-ID: <002e01c3c662$132a2690$2f0c6150@ioana> This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C3C672.D5E01630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable La algoritmul LRU-aging trebuie sa actualizam contoarele asociate = paginilor la fiecare "clock tick". In Tannenbaum scrie ca pentru = contoare pe 8 biti acest clock tick este cam de 20 msec. Asa trebuie sa = il luam si noi in program? Pentru WSClock trebuie sa stabilim un t (cu semnificatia ca paginile = referite in ultimele t sec sunt din WS). Acest t il stabilim cum vrem = noi? ------=_NextPart_000_002B_01C3C672.D5E01630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

La algoritmul = LRU-aging trebuie=20 sa actualizam contoarele asociate paginilor la fiecare "clock tick". In=20 Tannenbaum scrie ca pentru contoare pe 8 biti acest clock tick este cam = de 20=20 msec. Asa trebuie sa il luam si noi in program?

Pentru WSClock = trebuie sa=20 stabilim un t (cu semnificatia ca paginile referite in ultimele t sec = sunt din=20 WS). Acest t il stabilim cum vrem noi?

------=_NextPart_000_002B_01C3C672.D5E01630-- From so@atlantis.cs.pub.ro Sat Dec 20 09:57:53 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Sat, 20 Dec 2003 11:57:53 +0200 Subject: [so] tema5 In-Reply-To: <002e01c3c662$132a2690$2f0c6150@ioana> References: <002e01c3c662$132a2690$2f0c6150@ioana> Message-ID: On Fri, 19 Dec 2003 20:58:21 +0200, Ioana Cutcutache wrote: > La algoritmul LRU-aging trebuie sa actualizam contoarele asociate > paginilor la fiecare "clock tick". In Tannenbaum scrie ca pentru > contoare pe 8 biti acest clock tick este cam de 20 msec. Asa trebuie sa > il luam si noi in program? Nu. Puteti sa folositi orice valoare vreti, dar ca sa nu aveti probleme folositi o valoare mai mare de 100ms. > Pentru WSClock trebuie sa stabilim un t (cu semnificatia ca paginile > referite in ultimele t sec sunt din WS). Acest t il stabilim cum vrem > noi? Da. tavi From so@atlantis.cs.pub.ro Sat Dec 20 10:31:23 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Sat, 20 Dec 2003 12:31:23 +0200 Subject: [so] (no subject) Message-ID: Pentru ca tema 4 a fost trimisa de putin relative persoane, si pentru ca inca ne mai asteptam sa trimiteti tema, am revenit asupra deciziei initiale, si am hotarat ca sa nu se scada puncte din tema 4 in timpul vacantei. Asa ca, va urez vacanta placuta si La Multi Ani. tavi From so@atlantis.cs.pub.ro Sat Dec 20 13:33:59 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Sat, 20 Dec 2003 15:33:59 +0200 Subject: [so] tema5 References: <002e01c3c662$132a2690$2f0c6150@ioana> Message-ID: <000701c3c6fe$18fde0b0$700c6150@ioana> Putem folosi functia setitimer pentru a activa un timer (cel care sa ne trimeata semnalul cand trebuie actualizate contoarele)? Vad ca nu e POSIX, dar e singura functie pe care am gasit-o ce poate activa un timer ce masoara timpul de procesor al unui proces (timpul virtual) si pentru care se pot seta timpi mai mici de 1 secunda. Functia alarm poate activa doar timere de minim 1 secunda si sunt timere de timp real. Algoritmul WSClock spune ca daca sunt gasite pagini ce au age-ul > t , au R=0 si M=1, acestea trebuiesc programate sa fie scrise in swap. Aceste scrieri noi trebuie sa le facem asincron, sau am putea tine minte care a fost prima pagina de acest tip gasita si in caz ca nu gasim o pagina curata sa o scriem pe aceasta in swap si sa o inlocuim? From so@atlantis.cs.pub.ro Sat Dec 20 14:33:09 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Sat, 20 Dec 2003 16:33:09 +0200 Subject: [so] tema5 In-Reply-To: <000701c3c6fe$18fde0b0$700c6150@ioana> References: <002e01c3c662$132a2690$2f0c6150@ioana> <000701c3c6fe$18fde0b0$700c6150@ioana> Message-ID: On Sat, 20 Dec 2003 15:33:59 +0200, Ioana Cutcutache wrote: > Putem folosi functia setitimer pentru a activa un timer (cel care sa > ne > trimeata semnalul cand trebuie actualizate contoarele)? Vad ca nu e > POSIX, > dar e singura functie pe care am gasit-o ce poate activa un timer ce > masoara > timpul de procesor al unui proces (timpul virtual) si pentru care se pot > seta timpi mai mici de 1 secunda. Functia alarm poate activa doar timere > de > minim 1 secunda si sunt timere de timp real. Da. > Algoritmul WSClock spune ca daca sunt gasite pagini ce au age-ul > t, > au R=0 si M=1, acestea trebuiesc programate sa fie scrise in swap. Aceste > scrieri noi trebuie sa le facem asincron, sau am putea tine minte care a > fost prima pagina de acest tip gasita si in caz ca nu gasim o pagina > curata sa o scriem pe aceasta in swap si sa o inlocuim? > Cum doriti. Ambele variante au avantaje si dejavantaje. tavi From so@atlantis.cs.pub.ro Sat Dec 20 20:14:46 2003 From: so@atlantis.cs.pub.ro (Roxana Andrei) Date: Sat, 20 Dec 2003 12:14:46 -0800 (PST) Subject: [so] Tema5 Message-ID: <20031220201446.2767.qmail@web21104.mail.yahoo.com> Am o nelamurire legata de algoritmul wsclock : bitul R in cazul acestui algoritm se reseteaza la fiecare clock tick, sau doar atunci cand are loc un page fault si este parcursa lista circulara si sunt gasite pagini cu R=1? __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Sat Dec 20 20:17:07 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Sat, 20 Dec 2003 22:17:07 +0200 Subject: [so] tema5 References: <002e01c3c662$132a2690$2f0c6150@ioana> <000701c3c6fe$18fde0b0$700c6150@ioana> Message-ID: <008601c3c736$3e6a4860$700c6150@ioana> Pe zona de memorie virtuala se pot mapa pagini din fisierul cu memoria fizica (pt. ca atunci cand se fac scrieri modificarile sa se faca si in paginile corespunzatoare din memoria fizica)? From so@atlantis.cs.pub.ro Sun Dec 21 08:25:15 2003 From: so@atlantis.cs.pub.ro (Octavian PURDILA) Date: Sun, 21 Dec 2003 10:25:15 +0200 Subject: [so] tema5 In-Reply-To: <008601c3c736$3e6a4860$700c6150@ioana> References: <002e01c3c662$132a2690$2f0c6150@ioana> <000701c3c6fe$18fde0b0$700c6150@ioana> <008601c3c736$3e6a4860$700c6150@ioana> Message-ID: <1071995115.3fe558ebddc46@cs.pub.ro> Quoting Ioana Cutcutache : > Pe zona de memorie virtuala se pot mapa pagini din fisierul cu memoria > fizica (pt. ca atunci cand se fac scrieri modificarile sa se faca si in > paginile corespunzatoare din memoria fizica)? > > Da, chiar e recomandat. tavi ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From so@atlantis.cs.pub.ro Sun Dec 21 13:17:17 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Sun, 21 Dec 2003 15:17:17 +0200 Subject: [so] tema5 Message-ID: <002301c3c7c4$c2988a00$190c6150@ioana> This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C3C7D5.85485F20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Este ok daca fisierele cu swap-ul si cu memoria fizica sunt niste = fisiere temporare care in momentul cand se termina programul le sterg? = Sau ar trebui sa ramana ? ------=_NextPart_000_0020_01C3C7D5.85485F20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Este ok daca = fisierele cu=20 swap-ul si cu memoria fizica sunt niste fisiere temporare care in = momentul=20 cand se termina programul le sterg? Sau ar trebui sa ramana=20 ?

------=_NextPart_000_0020_01C3C7D5.85485F20-- From so@atlantis.cs.pub.ro Sun Dec 21 15:08:47 2003 From: so@atlantis.cs.pub.ro (Ionut Cirjan) Date: Sun, 21 Dec 2003 07:08:47 -0800 (PST) Subject: [so] subject email pe lista Message-ID: <20031221150847.1171.qmail@web41101.mail.yahoo.com> Am o rugaminte catre cei ce pun intrebari pe lista: Va rog, cand initiati un thread, puneti un subject sugestiv pentru ca sa fie mai usor celor care le citesc mai tarziu sa le deosebeasca. Voiam sa zic chestia asta mai demult. Acum o sa fie chair util asa ceva pentru ca vor fi multi care vor citi mailurile dupa vacanta, si probabil se vor strange cateva. Multumesc, Ionut. __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Mon Dec 22 12:41:59 2003 From: so@atlantis.cs.pub.ro (Octavian Purdila) Date: Mon, 22 Dec 2003 14:41:59 +0200 Subject: [so] tema5 In-Reply-To: <002301c3c7c4$c2988a00$190c6150@ioana> References: <002301c3c7c4$c2988a00$190c6150@ioana> Message-ID: On Sun, 21 Dec 2003 15:17:17 +0200, Ioana Cutcutache wrote: > Este ok daca fisierele cu swap-ul si cu memoria fizica sunt niste > fisiere temporare care in momentul cand se termina programul le sterg? > Sau ar trebui sa ramana ? Nu le stergeti, ca sa putem sa testam mai usor temele. tavi From so@atlantis.cs.pub.ro Tue Dec 23 10:40:23 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Tue, 23 Dec 2003 12:40:23 +0200 Subject: [so] help windows-mingw Message-ID: <000901c3c941$490a87f0$070c6150@ioana> Desi am luat update-ul pt. mingw pus pe site-ul de so nu imi merg functiile CreateTimerQueue, CreateTimerQueueTimer, AddVectoredExceptionHandler, RemoveVectoredExceptionHandler. La compilare mingw zice ca nu le gaseste. Ce pot sa fac? Pe windows ma gandeam sa folosesc un TimerQueueTimer pentru timer-ul necesar actualizarii contoarelor, este bine? Ideea e ca functia apelata va fi rulata intr-un alt fir de executie, dar alta solutie nu gasesc, un waitable timer nu as putea folosi pentru ca nu am cum sa fac asteptari. From so@atlantis.cs.pub.ro Tue Dec 23 11:23:25 2003 From: so@atlantis.cs.pub.ro (Ioana Cutcutache) Date: Tue, 23 Dec 2003 13:23:25 +0200 Subject: [so] help windows-mingw References: <000901c3c941$490a87f0$070c6150@ioana> Message-ID: <002101c3c947$aee80c90$070c6150@ioana> Mi-am dat seama de ce nu mergea CreateTimerQueue, trebuia sa definesc _WIN32_WINNT. Acum insa observ ca AddVectoredExceptionHandler, RemoveVectoredExceptionHandler nu exista in Win2000 !! Sa inteleg ca ne trebuie XP ca sa facem tema asta in win?? MinGW nici nu are suport pentru __try, __except.... ----- Original Message ----- From: "Ioana Cutcutache" To: Sent: Tuesday, December 23, 2003 12:40 PM Subject: [so] help windows-mingw > Desi am luat update-ul pt. mingw pus pe site-ul de so nu imi merg > functiile CreateTimerQueue, CreateTimerQueueTimer, > AddVectoredExceptionHandler, RemoveVectoredExceptionHandler. La compilare > mingw zice ca nu le gaseste. Ce pot sa fac? > Pe windows ma gandeam sa folosesc un TimerQueueTimer pentru timer-ul > necesar actualizarii contoarelor, este bine? Ideea e ca functia apelata va > fi rulata intr-un alt fir de executie, dar alta solutie nu gasesc, un > waitable timer nu as putea folosi pentru ca nu am cum sa fac asteptari. > > > > _______________________________________________ > so mailing list > so@atlantis.cs.pub.ro > http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so > From so@atlantis.cs.pub.ro Wed Dec 24 13:59:28 2003 From: so@atlantis.cs.pub.ro (Octavian PURDILA) Date: Wed, 24 Dec 2003 15:59:28 +0200 Subject: [so] help windows-mingw In-Reply-To: <002101c3c947$aee80c90$070c6150@ioana> References: <000901c3c941$490a87f0$070c6150@ioana> <002101c3c947$aee80c90$070c6150@ioana> Message-ID: <1072274368.3fe99bc0550c5@cs.pub.ro> > Mi-am dat seama de ce nu mergea CreateTimerQueue, trebuia sa definesc > _WIN32_WINNT. > Acum insa observ ca AddVectoredExceptionHandler, > RemoveVectoredExceptionHandler nu exista in Win2000 !! Sa inteleg ca ne > trebuie XP ca sa facem tema asta in win?? > MinGW nici nu are suport pentru __try, __except.... > Folositi SetUnhandledExceptionFilter care merge si cu Win2000 tavi > ----- Original Message ----- > From: "Ioana Cutcutache" > To: > Sent: Tuesday, December 23, 2003 12:40 PM > Subject: [so] help windows-mingw > > > > Desi am luat update-ul pt. mingw pus pe site-ul de so nu imi merg > > functiile CreateTimerQueue, CreateTimerQueueTimer, > > AddVectoredExceptionHandler, RemoveVectoredExceptionHandler. La compilare > > mingw zice ca nu le gaseste. Ce pot sa fac? > > Pe windows ma gandeam sa folosesc un TimerQueueTimer pentru timer-ul > > necesar actualizarii contoarelor, este bine? Ideea e ca functia apelata va > > fi rulata intr-un alt fir de executie, dar alta solutie nu gasesc, un > > waitable timer nu as putea folosi pentru ca nu am cum sa fac asteptari. > > > > > > > > _______________________________________________ > > so mailing list > > so@atlantis.cs.pub.ro > > http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so > > > > > > _______________________________________________ > so mailing list > so@atlantis.cs.pub.ro > http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From so@atlantis.cs.pub.ro Sun Dec 28 08:01:36 2003 From: so@atlantis.cs.pub.ro (Ruxi Jitianu) Date: Sun, 28 Dec 2003 10:01:36 +0200 Subject: [so] subiecte examen Message-ID: <3FEE8DE0.9070100@pcnet.ro> Am inteles ca ar trebui sa apara pe site niste subiecte posibile pentru examen. Nu se poate sa apara mai repede? Am putea sa mai citim cate ceva din Tanenbaum pentru a ne fi mai usor in sesiune, cand avem exagerat de putine zile ...... Multumesc! Ruxandra From so@atlantis.cs.pub.ro Mon Dec 29 18:39:49 2003 From: so@atlantis.cs.pub.ro (Herisanu Ioan) Date: Mon, 29 Dec 2003 10:39:49 -0800 (PST) Subject: [so] tema5 page access In-Reply-To: <20031225042503.24958.10537.Mailman@atlantis> Message-ID: <20031229183949.70647.qmail@web10305.mail.yahoo.com> Buna ziua, am cateva nelamuriri/ intrebari legate de tema 5, : 1.Din cate inteleg eu, memoria virtuala este in spatiul procesului curent. E posibil ca aplicatia sa aloce memori peste " memoria virtuala" ?( un malloc) Adica un malloc care sa inceapa inainte de "memoria virtuala" si sa se termine/continue in zona "memorie virtuala" 2.1Tema se refera la interceptarea apelurilor malloc/free HeapAlloc.. si la tratarea lor in spatiul de memorie "memorie viruala" mapata la "memorie fizica"= fisier? 2.2Sau se refera doar la apeluri de tip (*mem) = 'x' unde mem e in spatiul "memorie virtuala"? Daca da, atunci: 2.2.1Cum pot sti ca apelez un anume bloc de memorie virtuala? Stiu doar ce bloc este daca il setez cu PAGE_NOACCESS si folosesc un handler setat cu SetUnHandledExceptionFilter. Este posibil sa setez un fel de handler pt fiecare page?Un fel de Listener pt fiecare page din "memorie virtuala" chiar si la read? Un an nou cu bucurii pentru toti, Multumesc anticipat, Herisanu Ioan __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From so@atlantis.cs.pub.ro Mon Dec 1 01:01:22 2003 From: so@atlantis.cs.pub.ro (Daniel Cosmin Porumbel) Date: Sun, 30 Nov 2003 17:01:22 -0800 Subject: [so] upload mistake Message-ID: <001a01c3b7a6$a36a1b40$42c8100a@16.200.66.p16.pub.ro> This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C3B763.94C09440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Salut! Cred ca am facut o greseala la upload. Am vrut sa trimit tema = si nu mi-a primit-o dintr-un motiv oarecare. Apoi cand am vrut s-o = trimit iar, am dat back si n-am mai modificat dropDownListurile si s-a = pus peste tema1 de Windows. Credeti ca se mai poate face ceva ca sa = recuperez fisierele de dinainte? Sper ca nu face overwrite automat.... Toate bune! Dany ------=_NextPart_000_0017_01C3B763.94C09440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Salut!

Toate bune!

Dany

Salut!

1.Vine = un client.=20 Daca e loc liber de tuns(frizer dormind), GO TO 4

2.Daca = sunt scaune=20 libere se aseaza. Daca nu, pleaca definitiv.

3.Daca = toti frizerii=20 lucreaza, astept ca alt client sa iasa din frizerie(la 5) si astfel = sa=20 elibereze un frizer pe care sa il iau.

4.Am = prins loc de=20 tuns(sau frizer dormind-gata sa ma tunda), astept sa fiu = tuns

5.Am = fost tuns,=20 semnalizez pe unul blocat la 3 sa treaca mai departe ca acum are frizer=20 liber.

Acesta e comportamentul clientului. = Comportamentul frizerilor se deduce din = el:

La pasul 4 un frizer se = scoala sa=20 tunda.

La pasul 5 un frizer se = culca.

Fara sa mai faci nici o sincronizare, = poti sa-ti=20 dai seama care frizer se scoala si care frizer se culca. Tii niste liste = de=20 frizeri...

Daca cel care se culca la 5 va fi = trezit=20 imediat(la 3), atunci nici nu mai consideri ca se culca. Consideri = ca=20 invita un client la tuns.

Toate bune!

Dany

Ioana Cutcutache <ioana_c@pcnet.ro> wrote:

Intrebarea 1 : in enuntul temei 4 scrie "pentru operatiile asincrone
clienti pot sa specifice modul in care sa se faca notificarea terminarii
operatiei". Din asta inteleg ca trebui implementate ambele moduri de
notificare si ca modul este specificat de client. Asa este? Si daca este
asa, un client trebuie sa primeasca inca un argument in linia de comanda
care sa spuna ce mod alege? Iar un fir din server ce se ocupa de operatiile
de citire/scriere trebuie sa poata sa se ocupe simultan de operatii care au
asociate moduri diferite de notificare a terminarii, si deci sa fie
notificat diferit de terminarea operatiilor care le-a inceput?

Trebuie implementate ambele moduri de notificare, dar in surse separate.

Intrebarea 2 : in enunt scrie ca operatiile de citire si scriere din/in
fisier se fac in niste fire ale serverului ce se ocupa de asta, dar operatia
de listare a fisierelor dintr-un director trebuie si ea facuta intr-unul din
aceste fire, sau poate fi facuta in firul principal al serverului?

Intrebarea 3 : firele ce se ocupa de operatiile de citire/scriere pot sa
trimeata rezultatele la clienti sau ele doar fac citirea/scrierea si firul
principal va trimite rezultatele?

Serverul face doar load balancing.

_______________________________________________
so mailing list
so@atlantis.cs.pub.ro
http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so

Salut,

Evident raspunsul anterior este inadecvat.

George

"Serverul=20 trebuie sa se asigure ca thread-urile sunt egal = incarcate."

Ce inseamna egal incarcate? (nu ma = refer la=20 concept). Eu am in minte 2 variante dar nu le spun pentru ca nu vreau sa = dau=20 idei de enunt. :)

este ok daca din functia callback (in = cazul a) nu=20 facem altceva decat un SetEvent(event), unde "event" ar fi fost cel din = cazul b=20 ?

NU

Cibu Cristian <cibu.cristian@rdslink.ro> wrote:

este ok daca din functia callback (in cazul a) nu facem altceva decat un SetEvent(event), unde "event" ar fi fost cel din cazul b ?

Daca un client = trimite o cerere=20 de scriere intr-un fisier care nu exista, acel fisier este creat si in = el va fi=20 scris ce vrea clientul, sau se da eroare ca fisierul nu exista?

Clientului nu ar = trebui sa i se=20 dea adresa serverului?

Sarbatori fericite!

______________________= ______________________________
<= A href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&lang=3D9">= 3D""

Salut,

Raspunsul oficial pt cazul in care folosesti semnale pt notificare ar fi : structura sigevent din componenta structurii aiocb contine si un camp sigev_value ce indica valoarea trimisa cu

semnalul. Actiunea tipului de semnal pe care il ai in vedere trebuie setata folosind sigaction. Valorea va putea fi preluata in handler din structura siginfo_t primita ca parametru.

Ai aici un exemplu atasat (necomentat, dar ar tb sa fie destul de usor de inteles).

George

Dorin Moise <ddy@k.ro> wrote:

Sa inteleg ca raspunsul ioanei ramane oficial?
Vad ca nici unul dintre asistenti nu mi-a raspuns....

PS: Cand va fi corectata tema 1 la grupa 345CA?
-----------------------------------------
.dorin moise

Ioana Cutcutache so@atlantis.cs.pub.ro :

Daca te referi la cum determini care din operatiile asincrone s-a
terminat (daca ai pornit mai multe) folosesti functia aio_error si verifici
fiecare structura aiocb asociata unei operatii asincrone pornite. Aio_error
iti intoarce EINPROGRESS daca operatia nu s-a terminat inca. In felul asta
vezi care s-au terminat si faci cleanup-ul (inchidere fisier) si ce mai ai
nevoie sa faci.

----- Original Message -----
From: "Dorin Moise"
To:
Sent: Thursday, December 04, 2003 9:30 PM
Subject: [so] aiocb.aio_sigevent

>
>
> Cum ar trebui sa afle un "signal handler" ce operatie AIO s-a
incheiat?!?
>
> Spre exemplu, unul din cele X threaduri incepe o operatie asincrona -
dupa
> ce mai intai a deschis fisierul pe care "opereaza" - si specifica un
semnal
> care sa fie "declansat" cand operatia se incheie. Intrebarea e : cine va
> inchide fisierul?!?
> Thanks.
> -----------------------------------------
> .dorin moise
>
>

Sentimente.ro - www.sentimente.ro
Peste 50.000 de prieteni te asteapta!

_______________________________________________
so mailing list
so@atlantis.cs.pub.ro
http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so

Nu reusesc sa ma prind cum merge WriteFile cu OVERLAPPED.

In MSDN scrie

<quote>

</quote>

Am incercat sa scriu intr-un fisier 10Mb si apoi 30 Mb totul se intampla instant si deci am crezut ca este ok sa intoarca TRUE writefile.

codul este atasat

Raspuns:

WriteFile intoarece true cand termina de scris sau daca este OVERLAPPED cand

termina de facut pending, asa ca daca face pending intoarce true chiar daca operatia

nu s-a terminat.

deci programul dat merge bine (pana la proba contrarie)

Iancu <mail2mihai@yahoo.com> wrote:

Nu reusesc sa ma prind cum merge WriteFile cu OVERLAPPED.

In MSDN scrie

<quote>

If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the write operation starts at the offset specified in the OVERLAPPED structure and WriteFile may return before the write operation has been completed. In this case, WriteFile returns FALSE and the GetLastError function returns ERROR_IO_PENDING. This allows the calling process to continue processing while the write operation is being completed. The event specified in the OVERLAPPED structure is set to the signaled state upon completion of the write operation.

</quote>

Am incercat sa scriu intr-un fisier 10Mb si apoi 30 Mb totul se intampla instant si deci am crezut ca este ok sa intoarca TRUE writefile.

Apoi am scris 100Mb si dureaza cam 3 secunde, dar functia WriteFile nu intoarce FALSE imediat, ci asteapta sa faca scrierea. Ce este ciudat este ca Eventul din OVERLAPPED este semnazat deci nu cred ca am gresit in totalitate apelurile de functii.

codul este atasat

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard#include
#include
/*

HELPS FOR FINDING THE ERRORS RETURNED BY THE FUNCTIONS

*/
void PostError(const char* msg, DWORD dwErr, bool bTerminate){
LPVOID lpMsgBuf;

FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
dwErr,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
(LPTSTR) &lpMsgBuf,
0,
NULL);
printf("%s: %s\n", msg, (LPCSTR)lpMsgBuf);
// Free the buffer.
LocalFree( lpMsgBuf );
if (bTerminate)
ExitProcess(3);
}
/*

MAIN

*/

int main(){
//declare
char *lpBuffer = (char*) HeapAlloc(GetProcessHeap(),0,100*1024*1024);
DWORD dwBytesToWrite=100*1024*1024;
DWORD dwBytesWritten;
BOOL bResult;
OVERLAPPED ovrLpd1;
HANDLE hEvent;
//create event
hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
if (hEvent == INVALID_HANDLE_VALUE){
printf("error CreateEvent\n");
ExitProcess(2);
}
//create the overlapped structure
ovrLpd1.Offset = 0;
ovrLpd1.OffsetHigh = 0;
ovrLpd1.hEvent = hEvent;
//others
if (lpBuffer == NULL){
printf("error HeapAlloc()\n");
ExitProcess(1);
}
ZeroMemory((PVOID)lpBuffer,100*1024*1024);
//create file
HANDLE hFile = CreateFile(
"junk.file",
GENERIC_WRITE,
0,
NULL,
OPEN_ALWAYS,
FILE_FLAG_OVERLAPPED,
NULL);
if (hFile==INVALID_HANDLE_VALUE){
PostError("CreateFile: ",(int)GetLastError(), FALSE);
ExitProcess(1);
}
printf("called WriteFile\n");
bResult = WriteFile(
hFile,
lpBuffer,
dwBytesToWrite,
NULL,
&ovrLpd1);
printf("called WriteFile end\n");
GetOverlappedResult(hFile, &ovrLpd1, &dwBytesWritten, FALSE);
printf("%d\n", (int)dwBytesWritten);
if (!bResult)
PostError("WriteFile",GetLastError(), FALSE);
else
printf("File written - WriteFile returned TRUE ????\n");
printf("wating to finish async write\n");
WaitForSingleObject(hEvent, INFINITE);

CloseHandle(hFile);
HeapFree(GetProcessHeap(),0,lpBuffer);
return 0;
}

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Stie cineva din discutiile anterioare daca pe windows pt notificarea

terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu

pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Se poate folosi system

Toma Monica <moniqqus@yahoo.com> wrote:

Listarea fisierelor din director, folosind "ls" putem
folosi si apelul "system"?

=====

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

Daca toate threadurile cu notificare de tip b au ajuns la MAXIMUM_WAIT_OBJECTS poti

raspunde cu busy

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

E obligatorie folosirea functiei WaitForMultipleObjects, sau WaitForMultipleObjectsEx

Mihai Iancu <mail2mihai@yahoo.com> wrote:

Stie cineva din discutiile anterioare daca pe windows pt notificarea

terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu

pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

La firele de tip a nu se poate folosi=20 WaitForSingleObjectEx?

----- Original Message -----

From:=20 George=20 Ciobanu

To: so@atlantis.cs.pub.ro

Sent: Sunday, December 07, 2003 = 9:52=20 AM

Subject: Re: [so]=20 WaitForMultipleObjects

E obligatorie folosirea functiei WaitForMultipleObjects, sau=20 WaitForMultipleObjectsEx

Mihai Iancu <mail2mihai@yahoo.com>= wrote:=20

Stie cineva din discutiile anterioare daca pe windows pt=20 notificarea

terminarii unei operatii trebuie sa folosim = WaitForMultipleObjects=20 obligatoriu

pt threaduri de tip b? sau e posibil si cu=20 WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> = wrote:

WaitForMultipleObject are limita la handles de=20 MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT = requesturi=20 atribuite

unui thread dam raspuns de too busy sau gasim o = alternativa?

Do you Yahoo!?
Protect=20 your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect=20 your identity with Yahoo! Mail AddressGuard

La firele de tip a nu se poate folosi WaitForSingleObjectEx?

----- Original Message -----

From: George Ciobanu

To: so@atlantis.cs.pub.ro

Sent: Sunday, December 07, 2003 9:52 AM

Subject: Re: [so] WaitForMultipleObjects

E obligatorie folosirea functiei WaitForMultipleObjects, sau WaitForMultipleObjectsEx

Mihai Iancu <mail2mihai@yahoo.com> wrote:

Stie cineva din discutiile anterioare daca pe windows pt notificarea

terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu

pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing

Salut,

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

Toma Monica <moniqqus@yahoo.com> 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

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

Fisierele nu au o lungime maxima

George Ciobanu <cdangeorge@yahoo.com> 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 <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
& 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
>
> > ---------------------------------
> > 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

se depuncteaza folosirea write / read in loc de send / recv pe sockets ?

I dream of finding myself laughing!

nu. dar ar fi preferabil sa se utilizeze send/recv

Toma Monica <moniqqus@yahoo.com> wrote:

se depuncteaza folosirea write / read in loc de send / recv pe sockets ?

I dream of finding myself laughing!

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing

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.

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?
> > > 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

Intrebarile tale depind de modul tau de implementarea al problemei si tb rezolvate de tine ;)

Cristian Zamfir <zamfir@fx.ro> wrote:

1. Daca folosim un handler pentru semnalele care apar cind se termina o
operatie asincrona, nu imi dau seama cum putem sa sincronizam apelarea
handlerului cu threadul nostru.
Ma gindesc la urmatorul scenariu: Threadul care face cererile aio tocmai
modifica ceva in coada de cereri (sa zicem un delete ca urmare a terminarii
cu succes a unei alte cereri). Tocmai in mijlocul operatiei se termina o alta
operatie asincrona si se executa handler-ul pentru acel semnal, de catre
acest thread. Handlerul va face astfel acces nesincronizat la un anumit index
din coada (sa zicem ca primeste indexul ca parametru in structura siginfo_t).
Pe linga faptul ca indexul ar putea sa nu mai fie consistent, chiar si coada
ar putea sa nu mai fie, pentru ca tocmai se executa o operatie delete, si
cozile de obicei se fac cu liste inlantuite. Chiar daca sincronizam in
interiorul handler-ului accesul la coada, printr-un semafor, indexul, care e
primit ca parametru si nu poate sa fie sincronizat poate sa fie inconsistent.

2.Ce se intimpla in cazul in care doua cereri asincrone asociate aceluiasi
thread se termina cam in acelasi timp?

_______________________________________________
so mailing list
so@atlantis.cs.pub.ro
http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so

este necesar pt client sa suporte linii de comanda de tipul

client localhost .................. etc.

in enunt spune: client adresa_server ..................

iar localhost nu este o adresa.

fiind vorba efectiv de o parsare, putem = scurta=20 "rd", "wr" si "ls" la "r", "w" si "l"? evident cu menionarea acestui = fapt in=20 readme.

o idee buna, ca am vazut ca unele programe accepta si comenzi p= rescurtate

mersi de idee.

-------Original Message-------

From: so@atlantis.cs.pub.ro

Date: 9 decembrie = 2003 21:15:28

To: grup SO

Subject: [so] pars= are

fiind vorba efectiv de o parsare, putem = scurta "rd", "wr" si "ls" la "r", "w" si "l"? evident cu menionarea acest= ui fapt in readme.

______________________= ______________________________
<= A href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&lang=3D9">= 3D""

Nu am cautat prea mult sa vad daca pe site la tema sunt

si specificatii la socketii folositi pe windows.

Cei care folosesc <winsock2.h> sunt ok?

defapt acolo sunt socket si WSASocket, care trebuie folosit?

As prefera primul caci este mai esemanator cu cel din Linux

e ok prima alegere

Mihai Iancu <mail2mihai@yahoo.com> wrote:

Nu am cautat prea mult sa vad daca pe site la tema sunt

si specificatii la socketii folositi pe windows.

Cei care folosesc <winsock2.h> sunt ok?

defapt acolo sunt socket si WSASocket, care trebuie folosit?

As prefera primul caci este mai esemanator cu cel din Linux

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Ultima data la care puteti trimite teme este 18 ian 2003. Pentru tema 4,
penalizarile pe intarzieri
se vor face inclusiv pe zilele din vacanta.

tavi
_______________________________________________
so mailing list
so@atlantis.cs.pub.ro
http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so

Salut!

As avea si eu o = intrebare,=20 daca are timp cineva care a mai patit asa ceva...

Am un Segmentation=20 Fault care mi-a aparut doar pe un calculator(din 3 = incercate).

= -Efence nu=20 mi-a gasit nici un fel de buffer overrun/underrun.

Cum as putea sa mai=20 depanez?

Daca nu gasesc un = raspuns, ajung=20 ca domnul din imagine....

toate bune!

dany

Buna,

Eu am avut urmatoarea problema, si = poate tot asta=20 este si cauza problemei tale :

Segm fault respectiv (din ce am vazut = cu gdb) se=20 obtinea intr-un fir (altul decat cele create de mine) care era creat pt. = a face=20 operatia asincrona.

----- Original Message -----
From:=20 Daniel = Cosmin=20 Porumbel
To: so@atlantis.cs.pub.ro

Sent: Monday, December 15, 2003 = 9:29=20 PM

Subject: [so] depanare = program

Salut!

    As avea si eu = o=20 intrebare, daca are timp cineva care a mai patit asa = ceva...

    Am un Segmentation = Fault care mi-a aparut doar pe un calculator(din 3=20 incercate).

        = -Gdb mi-l=20 localizeaza pe ceva de genul pthread_exit(...) undevea in libc.so.6. , = deci=20 cand se termina un thread. Nici o referinta la o instructiune scrisa = de mine.=20 Apare la procedurile pe care le face el cand se termina un=20 thread.

        = -Efence nu=20 mi-a gasit nici un fel de buffer overrun/underrun.

    Cum as putea sa = mai=20 depanez?

    Daca nu gasesc un = raspuns,=20 ajung ca domnul din imagine....

toate bune!

dany

Pe tema de windows am folosit pt listare ls, e ok? Adica cel care corecteaza il are?

(George ...?)

Pentru WSClock = trebuie sa=20 stabilim un t (cu semnificatia ca paginile referite in ultimele t sec = sunt din=20 WS). Acest t il stabilim cum vrem noi?

Este ok daca = fisierele cu=20 swap-ul si cu memoria fizica sunt niste fisiere temporare care in = momentul=20 cand se termina programul le sterg? Sau ar trebui sa ramana=20 ?

Salut!

Toate bune!

Dany

Salut!

1.Vine = un client.=20 Daca e loc liber de tuns(frizer dormind), GO TO 4

2.Daca = sunt scaune=20 libere se aseaza. Daca nu, pleaca definitiv.

3.Daca = toti frizerii=20 lucreaza, astept ca alt client sa iasa din frizerie(la 5) si astfel = sa=20 elibereze un frizer pe care sa il iau.

4.Am = prins loc de=20 tuns(sau frizer dormind-gata sa ma tunda), astept sa fiu = tuns

5.Am = fost tuns,=20 semnalizez pe unul blocat la 3 sa treaca mai departe ca acum are frizer=20 liber.

Acesta e comportamentul clientului. = Comportamentul frizerilor se deduce din = el:

La pasul 4 un frizer se = scoala sa=20 tunda.

La pasul 5 un frizer se = culca.

Fara sa mai faci nici o sincronizare, = poti sa-ti=20 dai seama care frizer se scoala si care frizer se culca. Tii niste liste = de=20 frizeri...

Daca cel care se culca la 5 va fi = trezit=20 imediat(la 3), atunci nici nu mai consideri ca se culca. Consideri = ca=20 invita un client la tuns.

Toate bune!

Dany

Ioana Cutcutache <ioana_c@pcnet.ro> wrote:

Intrebarea 1 : in enuntul temei 4 scrie "pentru operatiile asincrone
clienti pot sa specifice modul in care sa se faca notificarea terminarii
operatiei". Din asta inteleg ca trebui implementate ambele moduri de
notificare si ca modul este specificat de client. Asa este? Si daca este
asa, un client trebuie sa primeasca inca un argument in linia de comanda
care sa spuna ce mod alege? Iar un fir din server ce se ocupa de operatiile
de citire/scriere trebuie sa poata sa se ocupe simultan de operatii care au
asociate moduri diferite de notificare a terminarii, si deci sa fie
notificat diferit de terminarea operatiilor care le-a inceput?

Trebuie implementate ambele moduri de notificare, dar in surse separate.

Intrebarea 2 : in enunt scrie ca operatiile de citire si scriere din/in
fisier se fac in niste fire ale serverului ce se ocupa de asta, dar operatia
de listare a fisierelor dintr-un director trebuie si ea facuta intr-unul din
aceste fire, sau poate fi facuta in firul principal al serverului?

Intrebarea 3 : firele ce se ocupa de operatiile de citire/scriere pot sa
trimeata rezultatele la clienti sau ele doar fac citirea/scrierea si firul
principal va trimite rezultatele?

Serverul face doar load balancing.

_______________________________________________
so mailing list
so@atlantis.cs.pub.ro
http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so

Salut,

Evident raspunsul anterior este inadecvat.

George

"Serverul=20 trebuie sa se asigure ca thread-urile sunt egal = incarcate."

Ce inseamna egal incarcate? (nu ma = refer la=20 concept). Eu am in minte 2 variante dar nu le spun pentru ca nu vreau sa = dau=20 idei de enunt. :)

este ok daca din functia callback (in = cazul a) nu=20 facem altceva decat un SetEvent(event), unde "event" ar fi fost cel din = cazul b=20 ?

NU

Cibu Cristian <cibu.cristian@rdslink.ro> wrote:

este ok daca din functia callback (in cazul a) nu facem altceva decat un SetEvent(event), unde "event" ar fi fost cel din cazul b ?

Daca un client = trimite o cerere=20 de scriere intr-un fisier care nu exista, acel fisier este creat si in = el va fi=20 scris ce vrea clientul, sau se da eroare ca fisierul nu exista?

Clientului nu ar = trebui sa i se=20 dea adresa serverului?

Sarbatori fericite!

______________________= ______________________________
<= A href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&lang=3D9">= 3D""

Salut,

Raspunsul oficial pt cazul in care folosesti semnale pt notificare ar fi : structura sigevent din componenta structurii aiocb contine si un camp sigev_value ce indica valoarea trimisa cu

semnalul. Actiunea tipului de semnal pe care il ai in vedere trebuie setata folosind sigaction. Valorea va putea fi preluata in handler din structura siginfo_t primita ca parametru.

Ai aici un exemplu atasat (necomentat, dar ar tb sa fie destul de usor de inteles).

George

Dorin Moise <ddy@k.ro> wrote:

Sa inteleg ca raspunsul ioanei ramane oficial?
Vad ca nici unul dintre asistenti nu mi-a raspuns....

PS: Cand va fi corectata tema 1 la grupa 345CA?
-----------------------------------------
.dorin moise

Ioana Cutcutache so@atlantis.cs.pub.ro :

Daca te referi la cum determini care din operatiile asincrone s-a
terminat (daca ai pornit mai multe) folosesti functia aio_error si verifici
fiecare structura aiocb asociata unei operatii asincrone pornite. Aio_error
iti intoarce EINPROGRESS daca operatia nu s-a terminat inca. In felul asta
vezi care s-au terminat si faci cleanup-ul (inchidere fisier) si ce mai ai
nevoie sa faci.

----- Original Message -----
From: "Dorin Moise"
To:
Sent: Thursday, December 04, 2003 9:30 PM
Subject: [so] aiocb.aio_sigevent

>
>
> Cum ar trebui sa afle un "signal handler" ce operatie AIO s-a
incheiat?!?
>
> Spre exemplu, unul din cele X threaduri incepe o operatie asincrona -
dupa
> ce mai intai a deschis fisierul pe care "opereaza" - si specifica un
semnal
> care sa fie "declansat" cand operatia se incheie. Intrebarea e : cine va
> inchide fisierul?!?
> Thanks.
> -----------------------------------------
> .dorin moise
>
>

Sentimente.ro - www.sentimente.ro
Peste 50.000 de prieteni te asteapta!

_______________________________________________
so mailing list
so@atlantis.cs.pub.ro
http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so

Nu reusesc sa ma prind cum merge WriteFile cu OVERLAPPED.

In MSDN scrie

<quote>

</quote>

Am incercat sa scriu intr-un fisier 10Mb si apoi 30 Mb totul se intampla instant si deci am crezut ca este ok sa intoarca TRUE writefile.

codul este atasat

Raspuns:

WriteFile intoarece true cand termina de scris sau daca este OVERLAPPED cand

termina de facut pending, asa ca daca face pending intoarce true chiar daca operatia

nu s-a terminat.

deci programul dat merge bine (pana la proba contrarie)

Iancu <mail2mihai@yahoo.com> wrote:

Nu reusesc sa ma prind cum merge WriteFile cu OVERLAPPED.

In MSDN scrie

<quote>

If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the write operation starts at the offset specified in the OVERLAPPED structure and WriteFile may return before the write operation has been completed. In this case, WriteFile returns FALSE and the GetLastError function returns ERROR_IO_PENDING. This allows the calling process to continue processing while the write operation is being completed. The event specified in the OVERLAPPED structure is set to the signaled state upon completion of the write operation.

</quote>

Am incercat sa scriu intr-un fisier 10Mb si apoi 30 Mb totul se intampla instant si deci am crezut ca este ok sa intoarca TRUE writefile.

Apoi am scris 100Mb si dureaza cam 3 secunde, dar functia WriteFile nu intoarce FALSE imediat, ci asteapta sa faca scrierea. Ce este ciudat este ca Eventul din OVERLAPPED este semnazat deci nu cred ca am gresit in totalitate apelurile de functii.

codul este atasat

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard#include
#include
/*

HELPS FOR FINDING THE ERRORS RETURNED BY THE FUNCTIONS

*/
void PostError(const char* msg, DWORD dwErr, bool bTerminate){
LPVOID lpMsgBuf;

FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
dwErr,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
(LPTSTR) &lpMsgBuf,
0,
NULL);
printf("%s: %s\n", msg, (LPCSTR)lpMsgBuf);
// Free the buffer.
LocalFree( lpMsgBuf );
if (bTerminate)
ExitProcess(3);
}
/*

MAIN

*/

int main(){
//declare
char *lpBuffer = (char*) HeapAlloc(GetProcessHeap(),0,100*1024*1024);
DWORD dwBytesToWrite=100*1024*1024;
DWORD dwBytesWritten;
BOOL bResult;
OVERLAPPED ovrLpd1;
HANDLE hEvent;
//create event
hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
if (hEvent == INVALID_HANDLE_VALUE){
printf("error CreateEvent\n");
ExitProcess(2);
}
//create the overlapped structure
ovrLpd1.Offset = 0;
ovrLpd1.OffsetHigh = 0;
ovrLpd1.hEvent = hEvent;
//others
if (lpBuffer == NULL){
printf("error HeapAlloc()\n");
ExitProcess(1);
}
ZeroMemory((PVOID)lpBuffer,100*1024*1024);
//create file
HANDLE hFile = CreateFile(
"junk.file",
GENERIC_WRITE,
0,
NULL,
OPEN_ALWAYS,
FILE_FLAG_OVERLAPPED,
NULL);
if (hFile==INVALID_HANDLE_VALUE){
PostError("CreateFile: ",(int)GetLastError(), FALSE);
ExitProcess(1);
}
printf("called WriteFile\n");
bResult = WriteFile(
hFile,
lpBuffer,
dwBytesToWrite,
NULL,
&ovrLpd1);
printf("called WriteFile end\n");
GetOverlappedResult(hFile, &ovrLpd1, &dwBytesWritten, FALSE);
printf("%d\n", (int)dwBytesWritten);
if (!bResult)
PostError("WriteFile",GetLastError(), FALSE);
else
printf("File written - WriteFile returned TRUE ????\n");
printf("wating to finish async write\n");
WaitForSingleObject(hEvent, INFINITE);

CloseHandle(hFile);
HeapFree(GetProcessHeap(),0,lpBuffer);
return 0;
}

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Stie cineva din discutiile anterioare daca pe windows pt notificarea

terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu

pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Se poate folosi system

Toma Monica <moniqqus@yahoo.com> wrote:

Listarea fisierelor din director, folosind "ls" putem
folosi si apelul "system"?

=====

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

Daca toate threadurile cu notificare de tip b au ajuns la MAXIMUM_WAIT_OBJECTS poti

raspunde cu busy

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

E obligatorie folosirea functiei WaitForMultipleObjects, sau WaitForMultipleObjectsEx

Mihai Iancu <mail2mihai@yahoo.com> wrote:

Stie cineva din discutiile anterioare daca pe windows pt notificarea

terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu

pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

La firele de tip a nu se poate folosi=20 WaitForSingleObjectEx?

----- Original Message -----

From:=20 George=20 Ciobanu

To: so@atlantis.cs.pub.ro

Sent: Sunday, December 07, 2003 = 9:52=20 AM

Subject: Re: [so]=20 WaitForMultipleObjects

E obligatorie folosirea functiei WaitForMultipleObjects, sau=20 WaitForMultipleObjectsEx

Mihai Iancu <mail2mihai@yahoo.com>= wrote:=20

Stie cineva din discutiile anterioare daca pe windows pt=20 notificarea

terminarii unei operatii trebuie sa folosim = WaitForMultipleObjects=20 obligatoriu

pt threaduri de tip b? sau e posibil si cu=20 WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> = wrote:

WaitForMultipleObject are limita la handles de=20 MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT = requesturi=20 atribuite

unui thread dam raspuns de too busy sau gasim o = alternativa?

Do you Yahoo!?
Protect=20 your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect=20 your identity with Yahoo! Mail AddressGuard

La firele de tip a nu se poate folosi WaitForSingleObjectEx?

----- Original Message -----

From: George Ciobanu

To: so@atlantis.cs.pub.ro

Sent: Sunday, December 07, 2003 9:52 AM

Subject: Re: [so] WaitForMultipleObjects

E obligatorie folosirea functiei WaitForMultipleObjects, sau WaitForMultipleObjectsEx

Mihai Iancu <mail2mihai@yahoo.com> wrote:

Stie cineva din discutiile anterioare daca pe windows pt notificarea

terminarii unei operatii trebuie sa folosim WaitForMultipleObjects obligatoriu

pt threaduri de tip b? sau e posibil si cu WaitForSIngleObject pt un semnal,

caci WaitForMO are limita de handles

Mihai Iancu <mail2mihai@yahoo.com> wrote:

WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.

Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi atribuite

unui thread dam raspuns de too busy sau gasim o alternativa?

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing

Salut,

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

Toma Monica <moniqqus@yahoo.com> 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

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

Fisierele nu au o lungime maxima

George Ciobanu <cdangeorge@yahoo.com> 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 <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
& 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
>
> > ---------------------------------
> > 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

se depuncteaza folosirea write / read in loc de send / recv pe sockets ?

I dream of finding myself laughing!

nu. dar ar fi preferabil sa se utilizeze send/recv

Toma Monica <moniqqus@yahoo.com> wrote:

se depuncteaza folosirea write / read in loc de send / recv pe sockets ?

I dream of finding myself laughing!

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing

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.

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?
> > > 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

Intrebarile tale depind de modul tau de implementarea al problemei si tb rezolvate de tine ;)

Cristian Zamfir <zamfir@fx.ro> wrote:

1. Daca folosim un handler pentru semnalele care apar cind se termina o
operatie asincrona, nu imi dau seama cum putem sa sincronizam apelarea
handlerului cu threadul nostru.
Ma gindesc la urmatorul scenariu: Threadul care face cererile aio tocmai
modifica ceva in coada de cereri (sa zicem un delete ca urmare a terminarii
cu succes a unei alte cereri). Tocmai in mijlocul operatiei se termina o alta
operatie asincrona si se executa handler-ul pentru acel semnal, de catre
acest thread. Handlerul va face astfel acces nesincronizat la un anumit index
din coada (sa zicem ca primeste indexul ca parametru in structura siginfo_t).
Pe linga faptul ca indexul ar putea sa nu mai fie consistent, chiar si coada
ar putea sa nu mai fie, pentru ca tocmai se executa o operatie delete, si
cozile de obicei se fac cu liste inlantuite. Chiar daca sincronizam in
interiorul handler-ului accesul la coada, printr-un semafor, indexul, care e
primit ca parametru si nu poate sa fie sincronizat poate sa fie inconsistent.

2.Ce se intimpla in cazul in care doua cereri asincrone asociate aceluiasi
thread se termina cam in acelasi timp?

_______________________________________________
so mailing list
so@atlantis.cs.pub.ro
http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so

este necesar pt client sa suporte linii de comanda de tipul

client localhost .................. etc.

in enunt spune: client adresa_server ..................

iar localhost nu este o adresa.

fiind vorba efectiv de o parsare, putem = scurta=20 "rd", "wr" si "ls" la "r", "w" si "l"? evident cu menionarea acestui = fapt in=20 readme.

o idee buna, ca am vazut ca unele programe accepta si comenzi p= rescurtate

mersi de idee.

-------Original Message-------

From: so@atlantis.cs.pub.ro

Date: 9 decembrie = 2003 21:15:28

To: grup SO

Subject: [so] pars= are

fiind vorba efectiv de o parsare, putem = scurta "rd", "wr" si "ls" la "r", "w" si "l"? evident cu menionarea acest= ui fapt in readme.

______________________= ______________________________
<= A href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&lang=3D9">= 3D""

Nu am cautat prea mult sa vad daca pe site la tema sunt

si specificatii la socketii folositi pe windows.

Cei care folosesc <winsock2.h> sunt ok?

defapt acolo sunt socket si WSASocket, care trebuie folosit?

As prefera primul caci este mai esemanator cu cel din Linux

e ok prima alegere

Mihai Iancu <mail2mihai@yahoo.com> wrote:

Nu am cautat prea mult sa vad daca pe site la tema sunt

si specificatii la socketii folositi pe windows.

Cei care folosesc <winsock2.h> sunt ok?

defapt acolo sunt socket si WSASocket, care trebuie folosit?

As prefera primul caci este mai esemanator cu cel din Linux

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Ultima data la care puteti trimite teme este 18 ian 2003. Pentru tema 4,
penalizarile pe intarzieri
se vor face inclusiv pe zilele din vacanta.

tavi
_______________________________________________
so mailing list
so@atlantis.cs.pub.ro
http://atlantis.cs.pub.ro/cgi-bin/mailman/listinfo/so

Salut!

As avea si eu o = intrebare,=20 daca are timp cineva care a mai patit asa ceva...

Am un Segmentation=20 Fault care mi-a aparut doar pe un calculator(din 3 = incercate).

= -Efence nu=20 mi-a gasit nici un fel de buffer overrun/underrun.

Cum as putea sa mai=20 depanez?

Daca nu gasesc un = raspuns, ajung=20 ca domnul din imagine....

toate bune!

dany

Buna,

Eu am avut urmatoarea problema, si = poate tot asta=20 este si cauza problemei tale :

Segm fault respectiv (din ce am vazut = cu gdb) se=20 obtinea intr-un fir (altul decat cele create de mine) care era creat pt. = a face=20 operatia asincrona.

----- Original Message -----
From:=20 Daniel = Cosmin=20 Porumbel
To: so@atlantis.cs.pub.ro

Sent: Monday, December 15, 2003 = 9:29=20 PM

Subject: [so] depanare = program

Salut!

    As avea si eu = o=20 intrebare, daca are timp cineva care a mai patit asa = ceva...

    Am un Segmentation = Fault care mi-a aparut doar pe un calculator(din 3=20 incercate).

        = -Gdb mi-l=20 localizeaza pe ceva de genul pthread_exit(...) undevea in libc.so.6. , = deci=20 cand se termina un thread. Nici o referinta la o instructiune scrisa = de mine.=20 Apare la procedurile pe care le face el cand se termina un=20 thread.

        = -Efence nu=20 mi-a gasit nici un fel de buffer overrun/underrun.

    Cum as putea sa = mai=20 depanez?

    Daca nu gasesc un = raspuns,=20 ajung ca domnul din imagine....

toate bune!

dany

Pe tema de windows am folosit pt listare ls, e ok? Adica cel care corecteaza il are?

(George ...?)

Pentru WSClock = trebuie sa=20 stabilim un t (cu semnificatia ca paginile referite in ultimele t sec = sunt din=20 WS). Acest t il stabilim cum vrem noi?