J'ai un stringstream défini globalament, et ensuite un programme
double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
gros, W tourne en boucle et filtre std::in pour R, le thread principal
(qui a créé W) et qui lit l'entrée filtrée dans le stringstream.
...et ça ne marche pas : W écrit bien dans le stream mais les getline
dans R ne retournent que des lignes vides. Une explication?
J'ai un stringstream défini globalament, et ensuite un programme
double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
gros, W tourne en boucle et filtre std::in pour R, le thread principal
(qui a créé W) et qui lit l'entrée filtrée dans le stringstream.
...et ça ne marche pas : W écrit bien dans le stream mais les getline
dans R ne retournent que des lignes vides. Une explication?
J'ai un stringstream défini globalament, et ensuite un programme
double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
gros, W tourne en boucle et filtre std::in pour R, le thread principal
(qui a créé W) et qui lit l'entrée filtrée dans le stringstream.
...et ça ne marche pas : W écrit bien dans le stream mais les getline
dans R ne retournent que des lignes vides. Une explication?
On 15 juil, 04:19, Mickybadia wrote:
> J'ai un stringstream défini globalament, et ensuite un programme
> double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
> gros, W tourne en boucle et filtre std::in pour R, le thread principal
> (qui a créé W) et qui lit l'entrée filtrée dans le stringstream .
Je suppose que le stringstream est protégé par un mutex.
> ...et ça ne marche pas : W écrit bien dans le stream mais
> les getline dans R ne retournent que des lignes vides. Une
> explication?
As tu vérifié l'état de ta stream ?
Je dirais que le eof bit est levé et tu ne détecte pas
l'erreur car tu ne le vérifie dans IO::readln().
On 15 juil, 04:19, Mickybadia <mickyba...@gmail.gmail.com> wrote:
> J'ai un stringstream défini globalament, et ensuite un programme
> double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
> gros, W tourne en boucle et filtre std::in pour R, le thread principal
> (qui a créé W) et qui lit l'entrée filtrée dans le stringstream .
Je suppose que le stringstream est protégé par un mutex.
> ...et ça ne marche pas : W écrit bien dans le stream mais
> les getline dans R ne retournent que des lignes vides. Une
> explication?
As tu vérifié l'état de ta stream ?
Je dirais que le eof bit est levé et tu ne détecte pas
l'erreur car tu ne le vérifie dans IO::readln().
On 15 juil, 04:19, Mickybadia wrote:
> J'ai un stringstream défini globalament, et ensuite un programme
> double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
> gros, W tourne en boucle et filtre std::in pour R, le thread principal
> (qui a créé W) et qui lit l'entrée filtrée dans le stringstream .
Je suppose que le stringstream est protégé par un mutex.
> ...et ça ne marche pas : W écrit bien dans le stream mais
> les getline dans R ne retournent que des lignes vides. Une
> explication?
As tu vérifié l'état de ta stream ?
Je dirais que le eof bit est levé et tu ne détecte pas
l'erreur car tu ne le vérifie dans IO::readln().
> Plus généralement, stringstream ne peut pas servir comme il
semble vouloir.
une std::deque< std::string > me semble tout
indiqué.)
> Plus généralement, stringstream ne peut pas servir comme il
semble vouloir.
une std::deque< std::string > me semble tout
indiqué.)
> Plus généralement, stringstream ne peut pas servir comme il
semble vouloir.
une std::deque< std::string > me semble tout
indiqué.)
>> J'ai un stringstream défini globalament, et ensuite un programme
double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
gros, W tourne en boucle et filtre std::in pour R, le thread principal
(qui a créé W) et qui lit l'entrée filtrée dans le stringstream.
Je suppose que le stringstream est protégé par un mutex.
>> J'ai un stringstream défini globalament, et ensuite un programme
double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
gros, W tourne en boucle et filtre std::in pour R, le thread principal
(qui a créé W) et qui lit l'entrée filtrée dans le stringstream.
Je suppose que le stringstream est protégé par un mutex.
>> J'ai un stringstream défini globalament, et ensuite un programme
double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
gros, W tourne en boucle et filtre std::in pour R, le thread principal
(qui a créé W) et qui lit l'entrée filtrée dans le stringstream.
Je suppose que le stringstream est protégé par un mutex.
>> J'ai un stringstream défini globalament, et ensuite un programme
>> double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
>> gros, W tourne en boucle et filtre std::in pour R, le thread principal
>> (qui a créé W) et qui lit l'entrée filtrée dans le stringstrea m.
> Je suppose que le stringstream est protégé par un mutex.
?!
Comprends pas. Au pire si yen avait un on ne ferait qu'attendre qu'il se
débloque non ?
>> J'ai un stringstream défini globalament, et ensuite un programme
>> double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
>> gros, W tourne en boucle et filtre std::in pour R, le thread principal
>> (qui a créé W) et qui lit l'entrée filtrée dans le stringstrea m.
> Je suppose que le stringstream est protégé par un mutex.
?!
Comprends pas. Au pire si yen avait un on ne ferait qu'attendre qu'il se
débloque non ?
>> J'ai un stringstream défini globalament, et ensuite un programme
>> double-thread, l'un (W) qui écrit dedans et l'autre (R) qui lit. En
>> gros, W tourne en boucle et filtre std::in pour R, le thread principal
>> (qui a créé W) et qui lit l'entrée filtrée dans le stringstrea m.
> Je suppose que le stringstream est protégé par un mutex.
?!
Comprends pas. Au pire si yen avait un on ne ferait qu'attendre qu'il se
débloque non ?
J'ai donc mutexé un deque<string> et implanté la lecture blocante (avec
une attente active pour l'instant – ne criez pas). Mais il y a autre
chose que je n'explique pas, la même en réalité que celle qui a lancé
mon 1er post. Le problème était déjà visible même avec les strinstreams
mal choisis, et toujours pas résolu : le lecteur ne voit pas les modifs
faites par l'écrivain. POURQUOI ??
J'ai donc mutexé un deque<string> et implanté la lecture blocante (avec
une attente active pour l'instant – ne criez pas). Mais il y a autre
chose que je n'explique pas, la même en réalité que celle qui a lancé
mon 1er post. Le problème était déjà visible même avec les strinstreams
mal choisis, et toujours pas résolu : le lecteur ne voit pas les modifs
faites par l'écrivain. POURQUOI ??
J'ai donc mutexé un deque<string> et implanté la lecture blocante (avec
une attente active pour l'instant – ne criez pas). Mais il y a autre
chose que je n'explique pas, la même en réalité que celle qui a lancé
mon 1er post. Le problème était déjà visible même avec les strinstreams
mal choisis, et toujours pas résolu : le lecteur ne voit pas les modifs
faites par l'écrivain. POURQUOI ??
> Plus généralement, stringstream ne peut pas servir comme il
> semble vouloir.
OK. En effet les stringstreams étant des iostreams je pensais
que ça ferait pareil, lecture blocante etc.
Merci de me l'indiquer. Au passage, je trouve alors bizarre
cet héritage. On n'est pas loin de ne tenir plus que par le
nom des méthodes et plus par les concepts modélisés par les
classes.
> une std::deque< std::string > me semble tout indiqué.)
C'est en effet une solution, juste qu'il me faut alors
implanter la lecture blocante moi-même. Un pipe à la limite...
> Plus généralement, stringstream ne peut pas servir comme il
> semble vouloir.
OK. En effet les stringstreams étant des iostreams je pensais
que ça ferait pareil, lecture blocante etc.
Merci de me l'indiquer. Au passage, je trouve alors bizarre
cet héritage. On n'est pas loin de ne tenir plus que par le
nom des méthodes et plus par les concepts modélisés par les
classes.
> une std::deque< std::string > me semble tout indiqué.)
C'est en effet une solution, juste qu'il me faut alors
implanter la lecture blocante moi-même. Un pipe à la limite...
> Plus généralement, stringstream ne peut pas servir comme il
> semble vouloir.
OK. En effet les stringstreams étant des iostreams je pensais
que ça ferait pareil, lecture blocante etc.
Merci de me l'indiquer. Au passage, je trouve alors bizarre
cet héritage. On n'est pas loin de ne tenir plus que par le
nom des méthodes et plus par les concepts modélisés par les
classes.
> une std::deque< std::string > me semble tout indiqué.)
C'est en effet une solution, juste qu'il me faut alors
implanter la lecture blocante moi-même. Un pipe à la limite...
Je reviens ici car il demeure une chose inexpliquée...
J'ai donc mutexé un deque<string> et implanté la lecture
blocante (avec une attente active pour l'instant ne criez
pas). Mais il y a autre chose que je n'explique pas, la même
en réalité que celle qui a lancé mon 1er post. Le problème
était déjà visible même avec les strinstreams mal choisis, et
toujours pas résolu : le lecteur ne voit pas les modifs faites
par l'écrivain. POURQUOI ??
Petit update du snippet donné avant ci-dessous. Encore une
fois, on boucle sur un affichage de "got in, size here is 0".
En traçant l'exec du thread créé on a tout bon par contre.
-----
static std::deque<string> fcin; // Filtered cin
static QMutex fcinAccess;
class IOThread : public QThread {
public:
void run() {
string ln;
while (getline(cin, ln)) {
if (filter(ln)) {
fcinAccess.lock();
fcin.push_back(ln);
cerr << "PUSHED a line in fcin queue (now size "
<< fcin.size() << "): " << ln << endl;
fcinAccess.unlock();
}
}
cout << "Reached end of input, IO exits." << endl;
}
};
class IO {
public:
IO() {
traceFlag = true;
io = new IOThread;
io->start();
}
private:
IOThread *io;
bool traceFlag;
public:
string readln() {
string line;
bool gotLine = false;
while (!gotLine) {
fcinAccess.lock();
cerr << "got in, size here is " << fcin.size() << endl;
if (!fcin.empty()) {
line = fcin.front();
fcin.pop_front();
gotLine = true;
}
fcinAccess.unlock();
}
trace("(input) " + line);
return line;
}
};
Je reviens ici car il demeure une chose inexpliquée...
J'ai donc mutexé un deque<string> et implanté la lecture
blocante (avec une attente active pour l'instant ne criez
pas). Mais il y a autre chose que je n'explique pas, la même
en réalité que celle qui a lancé mon 1er post. Le problème
était déjà visible même avec les strinstreams mal choisis, et
toujours pas résolu : le lecteur ne voit pas les modifs faites
par l'écrivain. POURQUOI ??
Petit update du snippet donné avant ci-dessous. Encore une
fois, on boucle sur un affichage de "got in, size here is 0".
En traçant l'exec du thread créé on a tout bon par contre.
-----
static std::deque<string> fcin; // Filtered cin
static QMutex fcinAccess;
class IOThread : public QThread {
public:
void run() {
string ln;
while (getline(cin, ln)) {
if (filter(ln)) {
fcinAccess.lock();
fcin.push_back(ln);
cerr << "PUSHED a line in fcin queue (now size "
<< fcin.size() << "): " << ln << endl;
fcinAccess.unlock();
}
}
cout << "Reached end of input, IO exits." << endl;
}
};
class IO {
public:
IO() {
traceFlag = true;
io = new IOThread;
io->start();
}
private:
IOThread *io;
bool traceFlag;
public:
string readln() {
string line;
bool gotLine = false;
while (!gotLine) {
fcinAccess.lock();
cerr << "got in, size here is " << fcin.size() << endl;
if (!fcin.empty()) {
line = fcin.front();
fcin.pop_front();
gotLine = true;
}
fcinAccess.unlock();
}
trace("(input) " + line);
return line;
}
};
Je reviens ici car il demeure une chose inexpliquée...
J'ai donc mutexé un deque<string> et implanté la lecture
blocante (avec une attente active pour l'instant ne criez
pas). Mais il y a autre chose que je n'explique pas, la même
en réalité que celle qui a lancé mon 1er post. Le problème
était déjà visible même avec les strinstreams mal choisis, et
toujours pas résolu : le lecteur ne voit pas les modifs faites
par l'écrivain. POURQUOI ??
Petit update du snippet donné avant ci-dessous. Encore une
fois, on boucle sur un affichage de "got in, size here is 0".
En traçant l'exec du thread créé on a tout bon par contre.
-----
static std::deque<string> fcin; // Filtered cin
static QMutex fcinAccess;
class IOThread : public QThread {
public:
void run() {
string ln;
while (getline(cin, ln)) {
if (filter(ln)) {
fcinAccess.lock();
fcin.push_back(ln);
cerr << "PUSHED a line in fcin queue (now size "
<< fcin.size() << "): " << ln << endl;
fcinAccess.unlock();
}
}
cout << "Reached end of input, IO exits." << endl;
}
};
class IO {
public:
IO() {
traceFlag = true;
io = new IOThread;
io->start();
}
private:
IOThread *io;
bool traceFlag;
public:
string readln() {
string line;
bool gotLine = false;
while (!gotLine) {
fcinAccess.lock();
cerr << "got in, size here is " << fcin.size() << endl;
if (!fcin.empty()) {
line = fcin.front();
fcin.pop_front();
gotLine = true;
}
fcinAccess.unlock();
}
trace("(input) " + line);
return line;
}
};