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

[Eric.NOULARD]

Le père qui meurt pour daemoniser?
Peux-tu m'envoyer le code qui fait ça:

Je m'attendais à ce que la fonction 'run' de ton
handler de requête soit justement ta boucle infinie auquel cas
tu rajoute un else et tu es peinard:

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);
        }
        else {
           msgrcv() ....
        }
}

Evidemment faudrait améliorer pour que la réception
du résultats des fils n'empêche pas le traitement d'autres
requêtes et que l'implem' ne viennent pas polluer le code même du
serveur que tu utilises... à voir vu que traiter 'n' requêtes
TSP simulatanéments n'est pas forcément un objectif...

Rajouter un mutex ne me gênes pas c'est juste que pour
l'instant nous avions des pthread_mutex et que je ne sais
pas si on peut les placer dans un SHM ni même si
pthread_mutex fonctionne ENTRE PLUSIEURS processus (fork)
sur toutes les archis.

Auquel cas il faut utiliser des semaphores POSIX (sem_open)
ou plutot sysV (semget) car les POSIX sont loins d'êtres
dispo everywhere.

Sinon d'un point de vue perf tu as raison et comme je disais
plus haut ce qu'on veut c'est que les "sample" soient performants
le traitements de 3 milliards de requêtes ben c'est moins grave
quand on voit le temps 'réseau' qui est pris par un RPC, XML-RPC, CORBA...


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.

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

Est-ce que j'ai raté qqchose dans ce que tu dis?

Eric
-------- Message d'origine--------
De:     address@hidden de la part de Frederik Deweerdt
Date:   mar. 22/03/2005 08:23
À:      Devel TSP
Cc:    
Objet:  Re: RE : [Tsp-devel] Ptit debriefing necessairey
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


_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel