[so] [tema2] sincronizare gateway - client

[Bogdan Purcareata]

> Eu cred ca din alta cauza se face wait dupa pid-urile clientilor ... daca
> te
> uiti cu atentie , spre sfarsitul scripturilor , e rulat un client care
> trimite
> "exit"
>

Am inteles de ce se face wait dupa pid-urile clientilor, incercam sa explic
de ce consider ca ar trebui facut wait si dupa pid-urile serverelor si al
gateway-ului. Intr-adevar, dupa ce toti clientii au primit raspuns la
cererile lor de decriptare, mai exista unul care da o comanda de exit, avand
rolul
de a finaliza executia proceselor gateway si server.


> ... ala termina serverele si gateway-ul pornite din scriptul curent (daca
> au
> functionalitatea ceruta), d-aia nu e nevoie sa se faca wait dupa pid-urile
> lor
>

Clientul care trimite comanda exit nu termina instantaneu serverele si
gateway-ul pornite din scriptul curent, ci declanseaza in ele o rutina de
terminare, care include, printre altele, inchiderea cozilor de mesaje si a
semafoarelor. Daca in aceasta perioada - de cand ultimul client a trimis
comanda de exit si pana cand se incepe executia unui nou test - serverele si
gateway-ul nu apuca sa inchida toate cozile si semafoarele, vor incepe alte
servere si alt gateway care vor deschide cozi / semafoare cu acelasi nume.

De exemplu, coada "gateway", folosita pentru comunicatia dintre clienti si
gateway, are mereu acelasi nume. Sa presupunem ca un gateway nu apuca sa se
termine si sa inchida coada pana cand un alt proces gateway a fost lansat in
executie. Procesul nou gateway va incerca sa _creeze_ aceeasi coada, apel
care va esua. Intre timp, se va termina procesul vechi gateway, care va
distruge aceasta coada, iar mai apoi clientul va incerca sa scrie intr-o
coada inexistenta.

Comportamentul acesta nedeterminist l-am observat pe implementarea mea, caci
rutina mea de finalizare a gateway-ului si serverelor se bazeaza pe
confirmari, nu se termina imediat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20110404/106dba0f/attachment-0001.htm>