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

[Frederik Deweerdt]

Le 22/03/05 00:16 +0100, Eric NOULARD écrivit:
> En y réfléchissant mieux je pense que ce serait au handler de requête
> XML-RPC de "faire ce qu'il faut avec ses fils" pour venir renseigner
> les structures actuelles.
> 
> En gros c'est au XML-RPC handler de se gérer sa SHM.
> Ce qui n'exclut pas de proposer un mini-wrapper pour ça dans
> tsp/util ou tsp/core/ipc.
> 
> Et a y réfléchir c'est une méthode bien bien louche de faire
> mourir le père une fois qu'il a engendré.
> On est plus au moyen âge :))

Le père qui meurt c'est uniquement pour daemonizer le serveur HTTP.
Ca se passe qu'une fois et ça posait problème puisque ça déclenchait
l'appel des fonctions enregistrées en atexit().

Après c'est un classique:
while (socket = accept) {
        if (fork() == 0) {
                // C'est dans ce process que sont créés (puis perdus)
                // les éléments de session
                runserver(socket); 
                exit(0);
        }
}
La stack doit ressembler à quelque chose comme:
fork
runserver
tsp_request_open_xmlrpc
TSP_provider_request_open
TSP_add_session  //C'est ici que sont allouées les données de session
-- fin du fils --

Tu parlerais d'une SHM spécifique dans tsp_server.c? Je pense que c'est 
dommage parce qu'on pourrait réutiliser ça pour une implementation
CORBA ou SOAP qui ait les mêmes caractéristiques...

L'overhead dans TSP_session serait:
- à l'init (allocation des shm)
- chaque fonction tsp_session, shmat si mappage pas fait
- lock, unlock lors de l'accès à la shared memory

Je ferais des benchmark mais je soupçonne un impact réduit sur les 
perfs RPC (prise des sémaphores sans jamais attendre)

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?

A+
Fred