Des streambufs et des pointeurs *pptr()

Le
Luc Hermitte
Bonjour,

Dans le cadre de la réalisation d'un ostream de log qui sera utilisé
dans un contexte multithread, je me suis défini un streambuf qui
mémorise dans des vecteurs (dans des TSS/TLS) ce qui circule dans
chaque thread.

Jusque là, tout va bien. Les articles de James m'ayant bien mis sur la
voie.

Et puis par curiosité, je suis allé voir ce qui se faisait ailleurs.
Sur codesearch de google, je suis tombé sur un code répondant à la
même question. Dans les différences notables, il y en a une qui m'a
intriguée : la mise à jour des pointeurs de la /put area/ avec setp(),
pbump(), etc.

Du coup, je me suis posé la question "mais est-ce bien nécessaire" ?
Si je ne m'abuse, ces pointeurs servent à tout ce qui est seekp/tellp.
Ce qui fait que dans mon contexte de logs (qui en plus se conclut par
un appel à une fonction variadique d'ACE), je n'en vois pas trop
l'intérêt. D'autant que je trouverait bizarre d'obtenir des valeurs
différentes suivant le thread qui utilise ces fonctions.

Suis-je passé à côté de quelque chose ?

--
Luc Hermitte
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
James Kanze
Le #2458801
On Apr 7, 12:10 pm, Luc Hermitte
Dans le cadre de la réalisation d'un ostream de log qui sera
utilisé dans un contexte multithread, je me suis défini un
streambuf qui mémorise dans des vecteurs (dans des TSS/TLS) ce
qui circule dans chaque thread.

Jusque là, tout va bien. Les articles de James m'ayant bien
mis sur la voie.

Et puis par curiosité, je suis allé voir ce qui se faisait
ailleurs. Sur codesearch de google, je suis tombé sur un code
répondant à la même question. Dans les différences notables,
il y en a une qui m'a intriguée : la mise à jour des pointeurs
de la /put area/ avec setp(), pbump(), etc.

Du coup, je me suis posé la question "mais est-ce bien
nécessaire" ? Si je ne m'abuse, ces pointeurs servent à tout
ce qui est seekp/tellp. Ce qui fait que dans mon contexte de
logs (qui en plus se conclut par un appel à une fonction
variadique d'ACE), je n'en vois pas trop l'intérêt. D'autant
que je trouverait bizarre d'obtenir des valeurs différentes
suivant le thread qui utilise ces fonctions.


Si tu veux des sorties bufferisées, il faut gerer les pointeurs.
Sinon, ce n'est pas la peine.

Ce que j'ai trouvé utile dans un log, c'est d'effectivement
collecter tout un enrégistrement dans un std::vector<> (par
exemple), puis de l'écrire d'un coup. (Sous Unix, l'écriture est
garantie atomique, au moins jusqu'une certaine taille, et avec
les bons paramètres en ouverture, elle est aussi garantie à la
fin de fichier.) Dans ce cas-là, le plus simple, c'est de
simplement faire un push_back() à chaque appel d'overflow(). On
pourrait bien cependant préférer l'utilisation du vector comme
un buffer ; dans ce cas-là, on l'agrandit dans overflow(), et on
met les pointeurs. Quelque chose du genre :

int
LogStreambuf::overflow(
int ch )
{
size_t current = myBuffer.size() ;
myBuffer.push_back( ch ) ;
myBuffer.resize( myBuffer.capacity() ) ;
setp( &myBuffer[ 0 ] + current,
&myBuffer[ 0 ] + myBuffer.size() ) ;
return ch ;
}

(J'ai negligé le cas où ch vaut EOF, pour simplifier.)

Ça reduit les appels virtuels, etc.

Aussi, il peut être intéressant d'avoir un streambuf par thread,
afin de ne pas avoir besoin des locks, ou au moins limiter le
temps qu'on les tient.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Luc Hermitte
Le #2464391
On 7 avr, 15:08, James Kanze
Si tu veux des sorties bufferisées, il faut gerer les pointeurs.
Sinon, ce n'est pas la peine.

Ce que j'ai trouvé utile dans un log, c'est d'effectivement
collecter tout un enrégistrement dans un std::vector<> (par
exemple), puis de l'écrire d'un coup. (Sous Unix, l'écriture est
garantie atomique, au moins jusqu'une certaine taille, et avec
les bons paramètres en ouverture, elle est aussi garantie à la
fin de fichier.) Dans ce cas-là, le plus simple, c'est de
simplement faire un push_back() à chaque appel d'overflow(). On
pourrait bien cependant préférer l'utilisation du vector comme
un buffer ; dans ce cas-là, on l'agrandit dans overflow(), et on
met les pointeurs. Quelque chose du genre :
[...]

Ça reduit les appels virtuels, etc.

Aussi, il peut être intéressant d'avoir un streambuf par thread,
afin de ne pas avoir besoin des locks, ou au moins limiter le
temps qu'on les tient.


OK. Merci pour ta réponse. J'ai passé un peu de temps à la murir, et
je pense avoir saisi maintenant.
Je comprends mieux du coup certains autres choix de l'autre code que
j'avais trouvé -- en gros il y a une classe "point d'accès" qui
renvoie un ostream localisé au thread courant (TSS).

Or, à cause d'une bibliothèque externe que j'intègre, et qui logge
dans ... std:::cout, je voulais limiter les indirections. Et donc
proposer un unique streambuf qui contient des vecteurs dans des TSS.
Je ne vois pas comment bufferiser plus : mon streambuf forcé dans
std::cout ne pouvant être bufferisé vu que les Xpptr() ne peuvent pas
être directement locaux à des threads.

Merci encore.

--
Luc Hermitte

Michel Decima
Le #2464371

Ce que j'ai trouvé utile dans un log, c'est d'effectivement
collecter tout un enrégistrement dans un std::vector<> (par
exemple), puis de l'écrire d'un coup.


Effectivement, écrire d'un coup c'est utile, surtout quand la
destination finale de l'enregistrement n'est pas le stream
qui sert au formattage du message.

Dans ce cas-là, le plus simple, c'est de simplement faire un
push_back() à chaque appel d'overflow(). On pourrait bien
cependant préférer l'utilisation du vector comme un buffer ;
dans ce cas-là, on l'agrandit dans overflow(), et on met les
pointeurs. Quelque chose du genre :

int
LogStreambuf::overflow(
int ch )
{
size_t current = myBuffer.size() ;
myBuffer.push_back( ch ) ;
myBuffer.resize( myBuffer.capacity() ) ;
setp( &myBuffer[ 0 ] + current,
&myBuffer[ 0 ] + myBuffer.size() ) ;
return ch ;
}


(J'ai negligé le cas où ch vaut EOF, pour simplifier.)

Ça reduit les appels virtuels, etc.


Tres joli. Merci pour l'astuce.

Aussi, il peut être intéressant d'avoir un streambuf par thread,
afin de ne pas avoir besoin des locks, ou au moins limiter le
temps qu'on les tient.


Oui, meme conclusion ici.

MD.

James Kanze
Le #2538041
On Apr 7, 4:42 pm, Luc Hermitte
On 7 avr, 15:08, James Kanze
Si tu veux des sorties bufferisées, il faut gerer les pointeurs.
Sinon, ce n'est pas la peine.

Ce que j'ai trouvé utile dans un log, c'est d'effectivement
collecter tout un enrégistrement dans un std::vector<> (par
exemple), puis de l'écrire d'un coup. (Sous Unix, l'écriture est
garantie atomique, au moins jusqu'une certaine taille, et avec
les bons paramètres en ouverture, elle est aussi garantie à la
fin de fichier.) Dans ce cas-là, le plus simple, c'est de
simplement faire un push_back() à chaque appel d'overflow(). On
pourrait bien cependant préférer l'utilisation du vector comme
un buffer ; dans ce cas-là, on l'agrandit dans overflow(), et on
met les pointeurs. Quelque chose du genre :
[...]

Ça reduit les appels virtuels, etc.

Aussi, il peut être intéressant d'avoir un streambuf par thread,
afin de ne pas avoir besoin des locks, ou au moins limiter le
temps qu'on les tient.


OK. Merci pour ta réponse. J'ai passé un peu de temps à la murir, et
je pense avoir saisi maintenant.
Je comprends mieux du coup certains autres choix de l'autre code que
j'avais trouvé -- en gros il y a une classe "point d'accès" qui
renvoie un ostream localisé au thread courant (TSS).


(C'est quoi, TSS ?)

Dans mes propres logs, le streambuf sert effectivement comme un
point d'accès. Une fois le buffer complet (un enrégistrement),
je le balance où il le faut, de façon atomique. Et où il le faut
pourrait bien être d'autres streambuf. (La première fois que
j'ai implémenté ce genre de choses, je me suis basé sur le
concepte des streambuf filtrants, et c'était bien des streambuf.
Depuis, je suis arrivé à la conclusion qu'une autre interface,
qui ne perd pas la notion de l'enrégistrement qu'on a si
soigneusement établie, conviendrait mieux, et mes LogStreambuf
contienent aujourd'hui un vector<LogWriter*> avec les
destinations, où LogWriter est une classe abstraite avec une
fonction virtuelle pure writeRecord.)

Or, à cause d'une bibliothèque externe que j'intègre, et qui logge
dans ... std:::cout, je voulais limiter les indirections. Et donc
proposer un unique streambuf qui contient des vecteurs dans des TSS.
Je ne vois pas comment bufferiser plus : mon streambuf forcé dans
std::cout ne pouvant être bufferisé vu que les Xpptr() ne peuvent pas
être directement locaux à des threads.


Si j'allais utiliser la mémoire propre au thread, c'est bien le
streambuf même que j'y mettrais ; la fonction log qui renvoie
le istream (ou le wrapper de l'istream) s'occuperait de le
trouver. Le nombre d'indirections reste le même, mais on reduit
le temps qu'on detient le lock -- si on sort directement avec
un write() Unix, on n'a même pas besoin du lock du tout.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Michel Decima
Le #2538001
On Apr 7, 4:42 pm, Luc Hermitte
OK. Merci pour ta réponse. J'ai passé un peu de temps à la murir, et
je pense avoir saisi maintenant.
Je comprends mieux du coup certains autres choix de l'autre code que
j'avais trouvé -- en gros il y a une classe "point d'accès" qui
renvoie un ostream localisé au thread courant (TSS).


(C'est quoi, TSS ?)


Surement une abbréviation de Thread Specific Storage.


Luc Hermitte
Le #2548761
On 8 avr, 11:09, Michel Decima

On Apr 7, 4:42 pm, Luc Hermitte
OK. Merci pour ta réponse. J'ai passé un peu de temps à la murir, et
je pense avoir saisi maintenant.
Je comprends mieux du coup certains autres choix de l'autre code que
j'avais trouvé -- en gros il y a une classe "point d'accès" qui
renvoie un ostream localisé au thread courant (TSS).


(C'est quoi, TSS ?)


Surement une abbréviation de Thread Specific Storage.


Oui, c'est bien l'idée. Suivant les auteurs ou les API, on aura /
Thread Local Storage/.
En gros, une abstraction de ce que l'on peut faire avec __thread (ou
équivalent)

--
Luc Hermitte



James Kanze
Le #2624111
On Apr 8, 11:09 am, Michel Decima
On Apr 7, 4:42 pm, Luc Hermitte
OK. Merci pour ta réponse. J'ai passé un peu de temps à la murir, et
je pense avoir saisi maintenant.
Je comprends mieux du coup certains autres choix de l'autre code que
j'avais trouvé -- en gros il y a une classe "point d'accès" qui
renvoie un ostream localisé au thread courant (TSS).


(C'est quoi, TSS ?)


Surement une abbréviation de Thread Specific Storage.


Voilà. J'avais à peu près déviné le « thread », mais la reste
m'a laissé perplexe, et Google donnait surtout des entrées pour
« toxic shock syndrome » (et j'étais assez sûr que ce n'était
pas ça qu'il voulais dire).

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



Michel Decima
Le #2624071
On Apr 8, 11:09 am, Michel Decima
(C'est quoi, TSS ?)


Surement une abbréviation de Thread Specific Storage.


Voilà. J'avais à peu près déviné le « thread », mais la reste
m'a laissé perplexe, et Google donnait surtout des entrées pour
« toxic shock syndrome » (et j'étais assez sûr que ce n'était
pas ça qu'il voulais dire).


Effectivement, ca n'a pas vraiment de rapport avec le sujet ;)
Ca me rappelle le jour ou j'ai cherché 'std' sur Google, le
résultat est assez surprenant pour un non anglophone...

MD.



Luc Hermitte
Le #2630351
On 9 avr, 09:37, James Kanze
(C'est quoi, TSS ?)
Surement une abbréviation de Thread Specific Storage.



Voilà. J'avais à peu près déviné le « thread », mais la rest e
m'a laissé perplexe, et Google donnait surtout des entrées pour
« toxic shock syndrome » (et j'étais assez sûr que ce n'était
pas ça qu'il voulais dire).


En effet. Ceci dit, avec "TSS c++" google envoie direct sur le papier
de Schmidt -- qui correspond à l'implémentation que j'utilise



James Kanze
Le #2645481
On Apr 9, 12:13 pm, Luc Hermitte
On 9 avr, 09:37, James Kanze
(C'est quoi, TSS ?)
Surement une abbréviation de Thread Specific Storage.



Voilà. J'avais à peu près déviné le « thread », mais la re ste
m'a laissé perplexe, et Google donnait surtout des entrées pour
« toxic shock syndrome » (et j'étais assez sûr que ce n'était
pas ça qu'il voulais dire).


En effet. Ceci dit, avec "TSS c++" google envoie direct sur le
papier de Schmidt -- qui correspond à l'implémentation que
j'utilise


C'est un bon tuyau, d'ajouter c++. J'avais bien essayé en
ajoutant quelque chose ("program", ou "computer", ou quelque
chose du genre), mais ça n'avait pas beaucoup aidé. Il faut bien
quelque chose que ne sert que dans l'informatique.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34




Publicité
Poster une réponse
Anonyme