[Tsp-devel] Mutex sur liste des sessions

[Stephane GALLES]

Selon address@hidden:
[...]
>
>
> Pour la protection du X_session_t elle
> tu as 2 MUTEX:
>
> Le MUTEX 'interne au core' pour les sessions:
>   TSP_LOCK_MUTEX(&X_session_list_mutex,);
> je connais pas trop son rôle, c'est Stéphane GALLES l'auteur :))
> Je pense qu'il protège les ajout/suppression de session.

J'avais du ajouter ce mutex, essentiellement à cause du garbage
collector de session (qui lui n'était pas protégé par l'aspect monothread
du serveur RPC, car il attaque de l'intérieur)

Il est peut être utilisé ailleurs, mais il faudrait que je
vérifie...

>
> Et le mutex introduit pour prévenir les accès concurrents
> par différents request_handler et/ou un request_handler
> concurrent à n'importe quelle requête TSP:
>
>   TSP_LOCK_MUTEX(&X_tsp_request_mutex,);
>
> Le mutex est pris en début de requête et relaché
> en fin de requête (request_open, request_sample, request_xxx....)
> dans  tsp_provider.c::TSP_provider_request_XXXX
>
> Et là c'est moi qui l'ait mis. C'est une sorte de
> BTRQL (Big TSP ReQuest Lock :)))
> des requêtes sur un provider, ce qui est moche mais efficace.
> On pourra le découper en mutex plus fin en passant au crible
> les interactions entre requêtes mais pour l'instant...
>
[...]

Eventuellement, par simplicité, on pourrait peut être enlever
le X_session_list_mutex et le remplacer par le X_tsp_request_mutex
nouvellement arrivé mais je parle sans regarder le code, et je
n'en ai en fait aucune idée (néanmoins, cela peut sembler logique
que de considérer que le garbage collector n'est aprés
tout qu'un client particulier, surtout que son travail est rapide)

Ou alors, peut être qu'on ferait aussi bien de ne pas toucher, comme
toujours avec les mutex  :)

Steph