Dans le cadre de la r=E9alisation d'un ostream de log qui sera utilis=E9
dans un contexte multithread, je me suis d=E9fini un streambuf qui
m=E9morise dans des vecteurs (dans des TSS/TLS) ce qui circule dans
chaque thread.
Jusque l=E0, tout va bien. Les articles de James m'ayant bien mis sur la
voie.
Et puis par curiosit=E9, je suis all=E9 voir ce qui se faisait ailleurs.
Sur codesearch de google, je suis tomb=E9 sur un code r=E9pondant =E0 la
m=EAme question. Dans les diff=E9rences notables, il y en a une qui m'a
intrigu=E9e : la mise =E0 jour des pointeurs de la /put area/ avec setp(),
pbump(), etc.
Du coup, je me suis pos=E9 la question "mais est-ce bien n=E9cessaire" ?
Si je ne m'abuse, ces pointeurs servent =E0 tout ce qui est seekp/tellp.
Ce qui fait que dans mon contexte de logs (qui en plus se conclut par
un appel =E0 une fonction variadique d'ACE), je n'en vois pas trop
l'int=E9r=EAt. D'autant que je trouverait bizarre d'obtenir des valeurs
diff=E9rentes suivant le thread qui utilise ces fonctions.
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 :
(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
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 :
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 :
(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
On 7 avr, 15:08, James Kanze 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
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.
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
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 :
(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.
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 :
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 :
(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
On Apr 7, 4:42 pm, Luc Hermitte wrote:
On 7 avr, 15:08, James Kanze 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: 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 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
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
On Apr 7, 4:42 pm, Luc Hermitte 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 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.
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
On 8 avr, 11:09, Michel Decima wrote:
On Apr 7, 4:42 pm, Luc Hermitte 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 8 avr, 11:09, Michel Decima <michel.dec...@orange-ft.com> wrote:
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)
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
On Apr 8, 11:09 am, Michel Decima wrote:
On Apr 7, 4:42 pm, Luc Hermitte 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: 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 Apr 8, 11:09 am, Michel Decima <michel.dec...@orange-ft.com> wrote:
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
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
On Apr 8, 11:09 am, Michel Decima wrote:
(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.
On Apr 8, 11:09 am, Michel Decima <michel.dec...@orange-ft.com> wrote:
(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...
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
On 9 avr, 09:37, James Kanze wrote:
(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
On 9 avr, 09:37, James Kanze <james.ka...@gmail.com> wrote:
(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
(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
On Apr 9, 12:13 pm, Luc Hermitte wrote:
On 9 avr, 09:37, James Kanze wrote:
(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
On Apr 9, 12:13 pm, Luc Hermitte <luc.hermi...@gmail.com> wrote:
On 9 avr, 09:37, James Kanze <james.ka...@gmail.com> wrote:
(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: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
(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
