RE: [Tsp-devel] Question sur le type 'String'

[PAGNOT Robert (EADS ASTRIUM)]

Eh oui, Robert is back !

Premièrement toutes mes félicitations pour vos élocubrations pleines de bon sens, même en période franchement plutôt propice aux gastro-entérites et autres crises de foie. Je vois que le sujet passione !

Puisque je dois dire quelque chose d'utile, je vous proposerai de gérer les string (et d'une manière générale tout élement de longueur variable) par deux zones mémoires.

1) LE ringbuf basique qui ne contient qu'un pointeur, à la place de la valeur (tableau de bytes) : peu de changements par rapport à l'état actuel car ce ringbuf serait à largeur constante et connue !

2) Un ou plusieurs ringbufs stockant de façon circulaire les élements à taille variable. La largeur serait égale au max (fourni par le provider), et profondeur calculée selon la fréquence de sampling.

On pourrait discuter sur le nombre de ringbufs à instancier (autant de ringbufs que d'élements, un seul ringbuf pour tous les éléments de longueur variable, ...), mais aussi sur la profondeur qui risque d'être difficile à modéliser !

Sans vouloir se torturer l'esprit, pensez que dans le cas des textes, il s'agira essentiellement de messages asynchrones, dont la fréquence de changement sera très lente par rapport aux données synchrones ! Limiter donc les paramètres à longueur variable en asynchrone (en gros - je transmet quand sa valeur change) ne serait pas très limitatif.

De plus, dissocier en termes de mémoire les paramètres à longueur variable (string, tableaux - de quoi déjà ?, ...) des paramètres à longueur fixe (doubles, int, ...) sera probablement plus efficace que de tout mélanger. Ce sont des paramètres de nature différente.

A+

        Robert

-----Message d'origine-----
De : Stephane Galles [mailto:address@hidden]
Envoyé : dimanche 4 janvier 2004 20:30
À : Ibou de Joie; tsp-devel
Objet : Re: [Tsp-devel] Question sur le type 'String'

OK, donc dans ma TODO list je passe en priorité :

"Comment implémenter un ringbuf qui gère des types variables ".

C'est vrai que je restais conservateur pour la taille des strings
parceque je n'avais pas envisagé de toucher de nouveau au RingBuf
(A cause du vieux precepte : "ca marche bien, et depuis longtemps;
donc t'evite de toucher avec tes gros doigts").

Mais pas de problèmes, on va voir comment modifier le RingBuf.

Par contre, je vais créer une batterie de tests unitaires qui vont
aller avec le nouveau RingBuf, et il faudra les passer sur
toutes les plateformes pour attraper tous les problèmes
d'alignement.

Je sens que cela va nécessiter un FrameWork de test un peu sérieux.
Je connais quelqu'un qui a utilisé un FrameWork de tests unitaires
il y a peu de temps. Je vais le contacter car il en était trés content.
Je crois que c'est CUnit (http://cunit.sourceforge.net/) mais il
faut que je vérifie.

Steph.

Ibou de Joie wrote:

>Et un ringbuf qui gere des types de taille variable (Une zone memoire
>commune globale, et on decale le ptr courant de la taille du dernier
>element) : Certes on ne sait pas exactement le nombre de truc que l'on
>peut y mettre, mais on connait leur occupation mémoire totale ? Ce doit
>etre un peu tricky pour les pb d'alignement, et donc sans doute moins
>efficace, mais à voir.
>
>Et je suis (comme d'hab) d'accord avec Eric, le provider doit pouvoir
>donner la taille max de chaque element à la connexion.
>
>Y++
>
>
>On Sat, 2004-01-03 at 13:13, Eric NOULARD wrote:
> 
>
>>Selon Stephane Galles <address@hidden>:
>>Euh très honnêtement je pense que 8 caractères c'est un peu
>>petit quiqui pour un Caribou de ta trempe.
>>
>>Je ne vois pas précisément le pb du ring buffer
>>car je n'ai pas le code sous la main là ou je suis
>>mais je pensais (bêtement) qu'une string avait une taille
>>a priori illimité mais que le provider annonçait au consumer
>>une taille MAX pour la session de sampling en cours de négoce.
>>Ensuite une fois la request_sample_init, on peut plus toucher
>>à la taille max, ce qui fait que le provider doit tailler
>>son ring-buf en fonction de ça.
>>
>>
>>   
>>
>>>Bon, je me suis lancé sur le codage des autres types, int, string, etc...
>>>J'ai commencé par le coté consumer. Je pense par contre que dans
>>>un premier temps, et quitte à me contredir, je ne vais pas utiliser
>>>les structures XDR pour la couche de transport. On vera cela
>>>dans un 2eme temps.
>>>
>>>Une question concernant le type 'String' : Il y a bien une taille max ?
>>>parceque si ce n'est pas le cas, je vais etre trés ennuyé pour les stocker
>>>dans un ringbuffer coté consummer.
>>>
>>>Donc je propose 8 charatères max pour les string. Simplement parceque
>>>les plus gros types (double et long long) font au max 8 octets et que donc
>>>on ne perd pas de place dans les ringbuf à cause des strings.
>>>
>>>j'espere que le besoin 'String' ne consiste pas à essayer de faire transiter
>>>des nombres en format string, sinon 8 charactères cela va etre un peu juste.
>>>
>>>J'avais compris ce besoin plutot pour faire passer des infos textuelles
>>>comme "ON", "OFF", etc ... Am I right ?
>>>     
>>>
>>Je pense que tu as raison, mais on peut vouloir faire transiter
>>un peu plus que 8 caractères.
>>
>>En gros, en ce qui concerne la taille max d'un string peut être dynamique
>>MAIS une fois que les sample sont en route celle-ci ne change plus.
>>
>>De façon plus général, le consumer "découvre" les types des symboles
>>(et donc leur taille) avec une request_info et/ou la premiere
>>request_sample ensuite ces tailles ne peuvent pas changer dès que les
>>sample ont commencés à transiter du provider au consumer.
>>
>>On pourrait imaginer que suite à un arrêt/redémarrage de la MEME
>>requete de sample la taille/le type d'un symbole est changé.
>>(si on oublie 30s le problème que ça pose côté provider).
>>
>>Qu'en penses-tu?
>>   
>>
>>>Stephane.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>Tsp-devel mailing list
>>>address@hidden
>>>http://mail.nongnu.org/mailman/listinfo/tsp-devel
>>>
>>>     
>>>
>>--
>>---
>>Erk
>>
>>
>>_______________________________________________
>>Tsp-devel mailing list
>>address@hidden
>>http://mail.nongnu.org/mailman/listinfo/tsp-devel
>>
>>   
>>
>
>
>
>
> 
>

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

This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.