Re: RE : [Tsp-devel] Ptit debriefing necessairey

[Stephane Galles]

Frederik Deweerdt wrote:

> D'ailleurs dans l'implémentation actuelle, les accès concurrents à X_session_t
> ne sont pas protégés par des sémaphores (ou j'ai besoin de repos :), ne 
> pourrait-on
> pas avoir des bogues en cas de plusieurs serveurs RPC?
>
>
>  

Vu que je ne trempe plus trop trop dans la partie C, prend ce que je te 
dis avec prudence,
mais si ma mémoire ne me trahit pas il n'y aura pas de problémes.

En effet (et à moins que cela n'ait changé entre temps) le serveur RPC 
du provider est initialisé
en mode monothread. Autrement dit le serveur RPC ne peut pas répondre à 
deux requêtes en même
temps. Les clients font la queue (mais le client est roi quand même, 
donc cela compense un peu)

Donc, c'est volontairement que les accès au X_session ne sont pas 
protégés, car la protection est là
par construction (en fait, je crois qu'Eric aurait voulu qu'on protège 
quand même, sans faire de suppositions
sur la manière dont est utilisées la couche RPC, mais je n'avais pas eu 
le temps)

En fait dans la spec initiale, le serveur RPC était multithread, mais 
pour la proof of concept,
on a fait au plus vite (KISS !), donc monothread, et comme au passage on 
gagnait l'exclusion
mutuelle des appels...on a fait encore plus vite en ne protégeant pas là 
où ce n'était pas nécessaire

Bon sinon :
- pour le n et n-1, bien sur que je suis OK (pour le découpage des libs 
je vote blanc)
- Pour le fork, si on ne peut pas faire autrement OK...mais je dois 
avouer que je suis du même avis
que Yves (et puis accessoirement, faire la chasse au rejetons/zombis à 
coup de ps | grep
cela devient vite fatiguant).

Steph