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