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: Eric.NOULARD
Subject: RE: [Tsp-devel] patch RPC cherche testeurs sous Solaris
Date: Thu, 28 Oct 2004 15:19:21 +0200


Je ne savais pas pour les points d'annulation et LinuxThread
en revanche j'ai fait mes tests avec une conf Linux en NPTL :))

Et je témoigne donc que ça marche nickel que ce soit
un read/write/poll/msgget/msgsnd etc...

J'utilise également l'annulation de thread chez un client
pour terminer proprement des threads qui font des appels
système bloquant et ça fonctionne également bien.

Ce que j'observe [avec stub_server ou bb_provider]
c'est que le thread s'arrête mais ensuite mon process
se termine en SIGSEGV DANS [la partie sun RPC de] la glibc :<<<

Pour compléter ce que tu as dit
un thread peut aussi demander explicitement
à ne pas honorer les demandes d'annulation
avec pthread_setcancelstate.

Eric

-----Original Message-----
From:   address@hidden on behalf of Stephane Galles
Sent:   Thu 10/28/2004 1:48 PM
To:     address@hidden
Cc:    
Subject:        Re: [Tsp-devel] patch RPC cherche testeurs sous Solaris
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

>



_______________________________________________
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]