tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tsp-devel] patch RPC cherche testeurs sous Solaris


From: Stephane Galles
Subject: Re: [Tsp-devel] patch RPC cherche testeurs sous Solaris
Date: Thu, 28 Oct 2004 07:48:58 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

Je n'ai peut être pas tout compris Eric, mais si ton test du pthread_cancel a été fait sur Linux, cela vaut le coup de tester sur DEC, car je pense qu'il est
normal que cela n'ai pas marché sur Linux.

Pour autant que je me rappel l'implementation Linux du pthread_cancel ne
fonctionne pas bien, car, je cite la doc :


POSIX spécifie qu'un certain nombre d'appels  systèmes  (fondamentalle-
      ment, tous les appels systèmes pouvant bloquer comme read(2), write(2),
      wait(2), etc.) et les fonctions  de  bibliothèques  qui  appellent  ces
      appels systèmes (par exemple, fprintf(3)) sont des points d'annulation.
      LinuxThreads n'est pas encore assez intégré à la bibliothèque standarde
      C  pour implémenter celà; et donc, aucune fonction de la glibc n'est un
      point d'annulation.

      Pour les appels systèmes, au moins existe-t'il un  moyen  détourné  d'y
      parvenir.   Les  requêetes d'annulation sont transmises au thread ciblé
      en lui envoyant un signal. Ce dernier va interrompre  tous  les  appels
      systèmes  bloquants,  les  faisant renvoyer immédiatement avec l'erreur
      EINTR. Aussi, vérifier qu'un thread n'a pas  été  annulé  au  cours  de
      l'appel  système  read,  par  exemple,  peut être réalisé de la manière
      suivante:

             pthread_testcancel();
             retcode = read(fd, tampon, longueur);
             pthread_testcancel();

Voila, voila...





address@hidden wrote:

Je pense pmpat_unset est insuffisant
il faut au moins de-enregistrer le service

svc_unregister
+
pmap_unset

le problème c'est même ça fait [apparemment] pas sortir svc_run
pour que tu évites de chercher j'ai aussi testé

un pthread_cancel sur le thread qu'on a lancé
et qui exécute svc_run.

Ca à l'air de marcher pas terrible, j'ai aussi un core dump mais avec une tronche différente.

Je suis pas arrivé à debugger car ça se termine
dans la glibc dont je n'aivait pas de version de
debug avec laquelle me linker.
...

En tous les cas si on a un souci multi-plateforme
be on peut aussi régler ça par
un

#ifdef DEC_OSF
ou #ifdef LINUX
etc...

Que la force soit avec toi Bob :))
Eric
-----Original Message-----
From:   address@hidden on behalf of
PAGNOT, Robert
Sent:   Thu 10/28/2004 8:39 AM
To:     tsp-devel
Cc:     
Subject:        RE: [Tsp-devel] patch RPC cherche testeurs sous Solaris
Gloups .....

J'avais commencé avec un svc_exit, mais cette fonction n'existe pas sous
DEC/OSF, alors j'étais dans la m....

Le problème consiste à forcer un return svc_run. Alors comment faire ?

Mon idée était de supprimer le mapping port/service (pmap_unset) pour
débloquer le select de svc_run (réponse à la question 1) de Erk). Puis de
libérer ce qui avait été alloué.

Le code de la 1.18 marche sur toutes les combinaisons que j'ai : Linux 2.4,
Solaris 2.5/2.8 et DEC/OSF 5.1.
Depuis peu je dispose d'un Linux 2.6, mais je n'ai vraiment pas eu le temps
de tester tout cela.

Je prends le patch, et j'essaye voir ce que cela donne ...

A+


Robert PAGNOT
ASTRIUM SAS
AEA56 - Ground Systems
tél.: 05 62 19 55 32 fax.: 05 62 19 77 41 <mailto:address@hidden>



-----Original Message-----
From: Stephane Galles [mailto:address@hidden
Sent: Thursday, October 28, 2004 1:00 AM
To: tsp-devel
Subject: Re: [Tsp-devel] patch RPC cherche testeurs sous Solaris



Oublie mon histoire de test sous Linux, on dirait bien que c'est nornal que cela plante.

Au niveau de la ligne de code dont tu parles on trouve :

STRACE_DEBUG(("calling svc_exit..."));
svc_destroy(config->xprt);

Le probleme est qu'on ne stoppe pas le svc_run, il faudrait :

STRACE_DEBUG(("calling svc_exit..."));
svc_exit();   /* svc_run s'arrete */
svc_destroy(config->xprt);

(encore que je ne sais plus si le svc_destroy est necessaire apres un exit)

J'ai vérifié dans CVS, le svc_exit était là jusqu'a la version 1.17, puis il a ete remplacé par le svc_destroy dans la 1.18. Mais comme je n'ai pas tout suivi du developpement de la partie C, je vous laisse vous arranger entre vous ;)


A+

Steph


NOULARD Eric wrote:

Après quelques investigations il s'avère que c'est la fonction svc_destroy
qui semble planter sous Linux (noyau 2.6.8.1 glibc 2.3.3)
si on l'enlève tout bonnement et qu'on fait
seulement

svc_unregister
pmap_unset

ben c'est ok??

D'où 2 questions:

1) A quoi sert réellement svc_destroy?
 l'argument de type SVCXPRT* qui est détruit par svc_destroy
 est utilise (probablement) par svn_run, suite au svc_tcpcreate
+svc_register. Hors svc_run ne revient jamais, donc que
se passe-t-il
 quand on "svc_destroy" quand svc_run n'est pas terminé?

2) est-ce que le patch qui suit serait OK sous Solaris
Patch applicable avec un
cd $DEVBASE
patch -p0 < rpc_linux.patch

Des volontaires pour tester ça sous Solaris
avant que je commite ces changements?

A noter que j'ai donné la version de la glibc car sous Linux
la lib [sun]rpc fait visiblement de la glibc
dans les sources (par exemple de la 2.3.3)
glibc-2.3.3/sunrpc/rpc/svc.h:

#define svc_destroy(xprt)                               \
      (*(xprt)->xp_ops->xp_destroy)(xprt)

Ce qui ne m'aide pas beaucoup...



-------------------------------------------------------------
-----------
Index: src/core/rpc/tsp_server.c
===================================================================
RCS file: /cvsroot/tsp/tsp/src/core/rpc/tsp_server.c,v
retrieving revision 1.18
diff -r1.18 tsp_server.c
39a40


/* FIXME a quoi sert ce define ? */
42a44,46


#include <rpc/pmap_clnt.h>
#include <stdio.h>
#include <unistd.h>
45a50


#include "../ctrl/tsp_provider.h"
50d54
< 51a56,60


#include "tsp_rpc_confprogid.h"

void
tsp_rpc_1(struct svc_req *rqstp, register SVCXPRT *transp) ;

54a64


#define TSP_URL_MAXLENGTH 256
58c68
<   char url[256];
---


char url[TSP_URL_MAXLENGTH];
64,71c74,76
< < static TSP_provider_info_t server_info;
<    
<   STRACE_IO(("-->IN"));
< < < server_info.info = GLU_get_server_name(); < ---


static TSP_provider_info_t server_info; 
STRACE_IO(("-->IN")); server_info.info = GLU_get_server_name();
73,75d77
< < < 84,93c86,88 < < < STRACE_IO(("-->IN")); < <
<   TSP_provider_request_open(&req_open, &ans_open);
<    
<   STRACE_IO(("-->OUT"));
< <
---


STRACE_IO(("-->IN"));      
TSP_provider_request_open(&req_open, &ans_open);        
STRACE_IO(("-->OUT"));     
117,119c112
<   STRACE_IO(("-->IN"));
< <
---


STRACE_IO(("-->IN"));      
121,124c114
< < STRACE_IO(("-->OUT")); < <
---


STRACE_IO(("-->OUT"));
135d124
< 137d125 < 150d137 < 160d146 < 173d158 < 180d164 < 183,186d166 < < < < 189d168
<    
200d178
< 202d179 < 221,224d197 < < void
< tsp_rpc_1(struct svc_req *rqstp, register SVCXPRT *transp) ;
< 260,261c233,234 < /* svc_create does not exist for linux, we must use the
deprecated function */
<   pmap_unset (rpc_progid, TSP_RPC_VERSION_INITIAL);
---


/* svc_create does not exist for linux, we must use the
deprecated function */
//pmap_unset (rpc_progid, TSP_RPC_VERSION_INITIAL);
285a259,261


//STRACE_DEBUG(("calling svc_exit..."));
//svc_destroy(config->xprt);

288a265


svc_unregister(TSP_get_progid(config->server_number),TSP_RPC_V
ERSION_INITIAL);
291,293d267
< < STRACE_DEBUG(("calling svc_exit..."));
<   svc_destroy(config->xprt);
314c288
< TSP_rpc_request_config_t *config =
(TSP_rpc_request_config_t *)this->config_param;
---


TSP_rpc_request_config_t *config =
(TSP_rpc_request_config_t *)(this->config_param);
318,319c292,294
<   strcpy(config->url, "");
< ---


/* do not buffer overflow */
memset(&config->url[0],'\0',TSP_URL_MAXLENGTH);

332c307,308
< sprintf(config->url, TSP_URL_FORMAT,
TSP_RPC_PROTOCOL, hostname, servername, config->server_number);
---


    snprintf(config->url, TSP_URL_MAXLENGTH,
TSP_URL_FORMAT, TSP_RPC_PROTOCOL, hostname,
servername, config->server_number);
346c322
< TSP_rpc_request_config_t *config =
(TSP_rpc_request_config_t *)this->config_param;
---


TSP_rpc_request_config_t *config =
(TSP_rpc_request_config_t *)(this->config_param);
350c326
<   pthread_detach(pthread_self()); /* FIXME shoudl we do this */
---


//pthread_detach(pthread_self()); /* FIXME shoudl we do this */
366c342
< TSP_rpc_request_config_t *config =
(TSP_rpc_request_config_t*)this->config_param;
---


TSP_rpc_request_config_t *config =
(TSP_rpc_request_config_t*)(this->config_param);
375c351
< TSP_rpc_request_config_t *config =
(TSP_rpc_request_config_t*)this->config_param;
---


TSP_rpc_request_config_t *config =
(TSP_rpc_request_config_t*)(this->config_param);
385c361
< void main(void)
---


int main(void)
392a369


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

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




------------------------------------------------------------------------

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]