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

On Apr 7, 12:10 pm, Luc Hermitte <luc.hermi...@gmail.com> wrote:

> 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:verflow(
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:james.kanze@gmail.com
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

On 7 avr, 15:08, James Kanze <james.ka...@gmail.com> wrote:
> 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

James Kanze a écrit :

> 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:verflow(
> 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.

On Apr 7, 4:42 pm, Luc Hermitte <luc.hermi...@gmail.com> wrote:
> On 7 avr, 15:08, James Kanze <james.ka...@gmail.com> wrote:
> > 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:james.kanze@gmail.com
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

James Kanze a écrit :
> On Apr 7, 4:42 pm, Luc Hermitte <luc.hermi...@gmail.com> wrote:

>> 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.

On 8 avr, 11:09, Michel Decima <michel.dec...@orange-ft.com> wrote:
> James Kanze a écrit :
>
> > On Apr 7, 4:42 pm, Luc Hermitte <luc.hermi...@gmail.com> wrote:
> >> 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

On Apr 8, 11:09 am, Michel Decima <michel.dec...@orange-ft.com> wrote:
> James Kanze a écrit :

> > On Apr 7, 4:42 pm, Luc Hermitte <luc.hermi...@gmail.com> wrote:
> >> 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:james.kanze@gmail.com
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