input non-bloquant

J'expérimente le comportement de streambuf::in_avail() pour voir si on peut
faire du non-bloquant avec, et chez moi (linux, gcc-3.3)
cin.rdbuf()->in_avail() est non bloquant et permet de bidouiller un peu,
par exple :

std::string s;
std::vector<char> v;
int navail;
size_t waits = 0;
while(std::cin && (s.size()==0 || s[s.size()-1]!='.') ) {
// s'arrete sur EOF, mais aussi sur '.' en fin de chaine
if((navail=cin.rdbuf()->in_avail() > 0 )) {
//s += "_"; // montre les bouts de in_avail
size_t sz = s.size();
v.resize(navail);
cin.read(& v[0], navail);
s.append(& v[0], navail);
}
else {
waits++;
sleep(1);
//std::cout<< "n s==["<< s <<"]" << std::endl;
}
}
std::cout<< "n--waits="<< waits<<" Final s==["<< s <<"]" << std::endl;

else {
waits++;
sleep(1);
//std::cout<< "n s==["<< s <<"]" << std::endl;
}
}
std::cout<< "n--waits="<< waits<<" Final s==["<< s <<"]" << std::endl;

Sans aller plus loin, une solution à base de wait ne m'intéresse pas
dans la plupart de mes applications. C'est une solution soit trop
gourmande en ressources, soit pas assez réactive.

le Thursday 15 January 2004 23:12, loic.actarus.joly@wanadoo.fr écrivit :

else {
waits++;
sleep(1);
//std::cout<< "n s==["<< s <<"]" << std::endl;
}
}
std::cout<< "n--waits="<< waits<<" Final s==["<< s <<"]" << std::endl;

Sans aller plus loin, une solution à base de wait ne m'intéresse pas
dans la plupart de mes applications. C'est une solution soit trop
gourmande en ressources, soit pas assez réactive.

hmm, j'imagine que ça dépend des applications. Pour du real-time ya de
fortes chances qu'il faudra de toute façon utiliser des features hyper
spécifiques au cas précis.
Je voudrais juste un moyen de faire que le programme fasse ce qu'il veut, et
regarde si il y a de l'input quand il le veut. Dans mon exemple j'ai rien à
faire, donc j'ai juste mis un sleep au lieu du corps du programme.

Le genre de truc que j'imagine, c'est un programme qui fait son truc, mais à
chaque itération de sa boucle jette un oeil sur un flux de contrôle. (pour
des messages, genre "stop", qui n'ont pas besoin d'être traité super
instantanément).

Mais en fait même si on veut une bonne réactivité, ce design peut très bien
fonctionner (ça sera au scheduler de l'os de bien faire son boulot). J'ai
un soft qui mets du son dans un buffer de 500ms, puis se mets en pause pour
70ms avant de recommencer à remplir tout ce qu'il peut, et je n'ai pas
constaté de problème dû à ce design processing/sleep/processing. La
réactivité est irréprochable, et la consommation de ressources négligeable.
Je pense que c'est parfaitement viable tant que le délai maximum toléré
reste assez loin de la granularité du scheduler.

Tes applications demandent une réactivité largement meilleure que cet ordre
de grandeur ?

et d'ailleurs tu fais comment, tu mets ton programme dans un sommeil spécial
qui s'interromp en cas d'input ?

C'est le genre de truc qui est
particulièrement non-portable, ou bien l'existence de possibilités
similaires sur qques OS permet d'unifier ça dans une interface C++
commune ?

Enfin bref, de toute façon même si on ne cherche pas une bonne réactivité,
on peut avoir besoin d'utiliser cin en non-bloquant..