Re : [Tsp-devel] Précisions sur tsp_hash.[ ch]

[eric.noulard]

En fait,

Et très honnêtement je pense que les hash_bob sont très
bien mais que dans notre cas vu qu'on veut une indirection entier --> entier
l'idée de Yves (tableau d'int taillé à nb_max_pgi) est la meilleure, ... pour 
l'instant.

En attendant qu'un volontaire, fasse une jolie
hash_bob qui prends comme clef des entiers et pas des strings.

Vu que faire des sprintf ou tout autre genre de cochonnerie
visant à transformer un entier en sa représentation textuelle
me paraît exagérée...

Du coup l'implém' actuelle peut être rapide
et dès qu'on a les hash_bob en entier.

Et je ne dis pas tout ça pour négliger les hash_bob...
qui me paraissent sincèrement très bien.


Mais ce n'est que mon avis.
---
Eric Noulard - Software Architect 
BT Consulting & Systems Integration
tel: (+33) (0)534 604970
web: www.bt.com/consulting



-------- Message d'origine--------
De: address@hidden de la part de Stef Euskadi
Date: mar. 29/11/2005 09:19
À: PAGNOT, Robert
Cc: TSP Devel ML
Objet : Re: [Tsp-devel] Précisions sur tsp_hash.[ch]
 
Le 29/11/05, PAGNOT, Robert <address@hidden> a écrit :
>
> *line 222 : free(hash) ?*
>
> Pour cela, il aurait fallu :
>
> int hash_close(hash_t **hash)
>         ...
>         free(*hash)
>         *hash = NULL
>         ...
>
> Je faisais cela par l'appellant.
>         ...
>         hash_close(p)
>         free(p)
>         p = NULL
>         ...
>
> Si tu estimes nécessaire, go-ahead pour les modifs !!!
>
Disons que, pour moi, si un composant alloue de la mémoire, il doit aussi la
libérer.
On peut peut-être se passer du double pointeur si on ne met plus la variable
à NULL.

 *MT-Safe* : a part le FIXME indiqué, le code est reentrant mais pas
> totalement MT-Safe (je ne sais pas ce que cela fait si tu fais un hash_get
> pendant qu'un autre thread fait un hash_append sur la même hash_table !!!).
>

Non, je me suis mal exprimé.
J'ai une hash table par thread. Donc je ne ferai jamais de GET en même temps
que APPEND.
Par contre, je peux faire en même temps de APPEND ou des GET sur des tables
différentes, dans des threads différents.


 Ceci étant, vaut mieux que la table soit "statique" : on fait tous les
> hash_append qui vont bien (car il y a des calloc's) au démarrage, puis on ne
> fait plus que des hash_get pendant les cycles. Mais la fonction* hash_get*
> est* MT-Safe*.
>
> *sprintf* : pénalisant, c'est sûr. Peut-être un lltostr (ou equivalent)
> serait plus efficace ?
>

OK, j'essaye ça. D'accord les autres ?

Euskadi.

 A+
>
>         Hash-ô-Bob
>   ---------------------------------------------------------
>
> CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT
> ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.
>
> SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE
> COURRIER, MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR
> COURRIER ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE
> CE COURRIER, VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE
> DISTRIBUER, LE COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE
> PARTIE.
>
>
>
> This email is for information only and will not bind EADS Astrium SAS in
> any contract or obligation, nor its subsidiaries.
>
> If you have received it in error, please notify the sender by return
> email. If you are not the addressee of this email, you must not use, keep,
> disseminate, copy, print or otherwise deal with it.
>
> ---------------------------------------------------------
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>
>
>