Un thread énergivore

Version imprimable

Bonjour à toutes et à tous,

Je code une application GPS se servant d'un GPS blueTooth externe. Tout fonctionne très bien, sauf que mon appli me vide la batterie à la vitesse grand V (j'ai réussi à coincer un ampèremètre entre la batterie et le smartphone pour le vérifier).

J'y ai mis du temps, mais j'ai réussi à voir d'où vient le problème. Le thread qui lit les informations en provenance du GPS tourne en permanence : boucle while(true). Avec un petit compteur (tc), j'ai pu vérifier que cette boucle est parcourue environ 80000 fois par seconde ... une à deux fois me suffisent.

Comment résoudre ce problème ? A mon sens, il faudrait lancer ce thread quelques fois par secondes, mais comment ?

Je suppose que vous avez des idées.

Merci de votre aide.

Pierre
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 private class ReceiverThread extends Thread { Handler handler; ReceiverThread(Handler h) { handler = h; } @Override public void run() { while(true) { tc = tc+1; try { if(receiveStream.available() > 0) { byte buffer[] = new byte[100]; int k = receiveStream.read(buffer, 0, 100); if(k > 0) { byte rawdata[] = new byte[k]; for(int i=0;i<k;i++) rawdata[i] = buffer[i]; String data = new String(rawdata); Message msg = handler.obtainMessage(); Bundle b = new Bundle(); b.putString("receivedData", data); msg.setData(b); handler.sendMessage(msg); } } } catch (IOException e) { e.printStackTrace(); } } } }

en java traditionnel, on ajoute un "sleep" dans le Thread:

Code:

1
2
3
4
5
            try {
                sleep(500); // attente d'une 1/2 seconde
            } catch (InterruptedException ex) {
                ex.printStackTrace();
            }

je suppose que cela existe pour android

ce qui donnerait :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
	private class ReceiverThread extends Thread {
		Handler handler;
		ReceiverThread(Handler h) {
			handler = h;
		}
		@Override public void run() {
			while(true) {
				tc = tc+1;
				try {
					if(receiveStream.available() > 0) {
						byte buffer[] = new byte[100];
						int k = receiveStream.read(buffer, 0, 100);
						if(k > 0) {
							byte rawdata[] = new byte[k];
							for(int i=0;i<k;i++)
								rawdata[i] = buffer[i];							
							String data = new String(rawdata);
							Message msg = handler.obtainMessage();
							Bundle b = new Bundle();
							b.putString("receivedData", data);
			                msg.setData(b);
			                handler.sendMessage(msg);
						}
					}
				} catch (IOException e) {
					e.printStackTrace();
				}

                                 try {
                                      sleep(500); // attente d'une 1/2 seconde
                                  } catch (InterruptedException ex) {
                                      ex.printStackTrace();
                                  }
			}
		}
	}

Salut,

Citation:

Envoyé par Népomucène

en java traditionnel, on ajoute un "sleep" dans le Thread:

Oui c'est bien ce qu'il faut pour faire et pause, et empêcher une attente active de bouffer tout le CPU comme c'est le cas...

Mais désolé ce n'est pas vraiment une belle solution dans ce cas là, car pour moi le problème vient de l'utilisation d'available() qui est totalement inutile et contre-productif !
On a une boucle d'I/O non-bloquante avec available()... et maintenant on voudrais la rendre bloquante avec des sleep().

:arrow: Autant lire directement l'InputStream, ce sera bloquant sans rien bricoler.

available() est inutile dans la grande majorité des cas (tout comme Reader.ready() au passage).
Pire il peut même être la source d'erreur ou de problème (comme ici).
En plus de 10 ans d'expérience Java et à fréquenter les forums de DVP je n'ai jamais vu une utilisation d'available() qui soit utile/correcte.

Au passage il est préférable de sortir le "buffer" de la boucle (pour éviter de le recréer à chaque fois), et le "rawdata" est inutile puisqu'on a un constructeur de String adapté...
Quand au e.printStackTrace() pour gérer l'exception c'est pas tip-top. Si on ne sait pas quoi faire autant l'englober dans une RuntimeException.

Bref pour moi cela donnerait quelque chose comme cela :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 @Override public void run() { try { byte buffer[] = new byte[100]; int k; while ((k = receiveStream.read(buffer, 0, 100)) > 0) { String data = new String(buffer, 0, k); Message msg = handler.obtainMessage(); Bundle b = new Bundle(); b.putString("receivedData", data); msg.setData(b); handler.sendMessage(msg); } } catch (IOException e) { throw new RuntimeException(e); } }
:arrow: Et le thread sera mis en sommeil tant qu'il n'y a aucune donnée à lire...

a++

05/01/2015, 15h44
ChPr

J'avais d'emblée, sans l'avoir même essayée écarté cette solution car je m'étais dit que le sleep(xxx) n'était qu'une boucle bouffe temps. C'est vrai, à la grosse différence près qu'elle ne consomme rien :D.

Donc, un grand merci à toi Népomucène de m'avoir remis sur les rails.

Mon appli sans sleep() consomme 0.5 A.

Elle ne consomme plus que 0.2 A avec ; c'est-à-dire à peu près la même chose que lorsque je n'exécute pas le thread.

Cordialement.

Pierre
05/01/2015, 15h58
Népomucène

@ChPr je pense qu'il faut que tu creuses aussi l'analyse d'adiGuba (beau travail ;))
pour faire un code "bien propre" et à nouveau mesurer la consommation.
05/01/2015, 16h07
adiGuba

Citation:

Envoyé par Népomucène

@ChPr je pense qu'il faut que tu creuses aussi l'analyse d'adiGuba (beau travail ;))
pour faire un code "bien propre" et à nouveau mesurer la consommation.

La différence de consommation sera identique ou presque.
Le sleep() corrige cela en faisant passer le traitement de 80000 itérations par secondes à 2 itérations seulement.

C'est juste que c'est se compliquer la vie pour rien, et que la manière directe est à la fois plus simple et plus efficace.

a++
05/01/2015, 17h20
ChPr

adiGuba, j'ai mis en œuvre ta solution : ça fonctionne très bien. cependant quelques questions.
lorsque je me déconnecte, le throw new RuntimeException(e); me fait planter mon application, je l'ai remplacé par ne rien faire : ça marche.

Je n'ai pas bien compris le fonctionnement de ton thread. Dans celui du départ, grâce à la boucle while(true), on ne sortait jamais du thread ; c'est ce qui en causait la grosse consommation. Dans ce que tu proposes, si k <= 0 on sort de la boucle. Je n'ai pas pu le vérifier, mais alors, que se passe-t-il ? qui relance le thread ?

Question annexe : mon message fait entre quelques caractères et environ 500 caractères. Quelle est la taille la mieux adaptée à prendre pour le buffer ?

Cordialement.

Pierre
05/01/2015, 17h45
Népomucène

Citation:

mon message fait entre quelques caractères et environ 500 caractères

Euh là ...
Cela veut dire que ton message n'est peut-être pas complet au moment où le Thread va le lire.

Y-a-t-il une marque de début et de fin de ton message ?
ou tout au moins une marque de fin genre "\n" ou autre pour qu'on soit sûr qu'on est au bout ?

Citation:

Envoyé par Népomucène

... Y-a-t-il une marque de début et de fin de ton message ?
ou tout au moins une marque de fin genre "\n" ou autre pour qu'on soit sûr qu'on est au bout ?

C'est un ensemble de phrases NMEA qui se répètent toutes les secondes et qui ont l'allure suivante :
Code:

1 2 3 4 5 6 7 $GPGGA,151621.000,4859.6001,N,00210.4451,E,2,11,0.82,66.8,M,47.2,M,0000,0000*5C $GPGSA,A,3,02,10,06,30,05,07,13,09,16,23,20,,1.11,0.82,0.74*01 $GPGSV,4,1,14,10,78,296,21,09,66,060,24,07,55,145,32,02,47,280,18*74 $GPGSV,4,2,14,06,47,211,26,23,34,066,15,30,30,178,38,05,20,297,17*73 $GPGSV,4,3,14,13,14,244,13,16,13,055,19,20,12,120,18,44,08,110,*72 $GPGSV,4,4,14,29,06,336,16,03,03,117,*77 $GPRMC,151621.000,A,4859.6001,N,00210.4451,E,2.10,148.93,201214,,,D*6B
Selon les infos venant des satellites de la constellation GPS ces phrases sont plus ou moins complètes. Je me sers du marqueur "$GPGGA" pour scinder chaque groupe. Le thread cité plus haut envoie ces données à la procédure suivante qui fait la césure entre chaque groupe :
Code:

1 2 3 4 5 6 7 8 9 10 11 final Handler handlerNMEA = new Handler() { // constitution d'une phrase NMEA complète public void handleMessage(Message msg) { String data = msg.getData().getString("receivedData"); phrase = phrase+data; // on compile les infos jusqu'à ... int pd = phrase.indexOf("$GPGGA"); // ce qu'on y trouve "$GPGGA" if (pd >= 0) { // si trouvé ... gestionInfoNMEA("$GPGGA"+phrase.substring(0, pd)); // ... récupération des données pour exploitation phrase = phrase.substring(pd+6); // réinitialisation de la phrase à ce qu'il y avait en trop pour recompléter la compilation : voir début de la procédure } } };
Cordialement.

Pierre

Donc le Thread doit envoyer en permanence les données à gestionInfoNMEA qui se débrouille.

Ceci veut dire que pour que cela fonctionne, le Thread ne doit jamais se terminer.
On en revient à la boucle while et au sleep(500)
et en tenant compte des remarques d'Adiguba :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
	private class ReceiverThread extends Thread {
		Handler handler;
		ReceiverThread(Handler h) {
			handler = h;
		}
		@Override public void run() {
			byte buffer[] = new byte[100];
			while(true) {
                                 		try {
                                 			int k;
                                 			while ((k = receiveStream.read(buffer, 0, 100)) > 0) {
                                 				String data = new String(buffer, 0, k);
                                 				Message msg = handler.obtainMessage();
                                 				Bundle b = new Bundle();
                                 				b.putString("receivedData", data);
                                 				msg.setData(b);
                                 				handler.sendMessage(msg);
                                 			}
                                 		} catch (IOException e) {
                                 			throw new RuntimeException(e);
                                 		}
 
                                 		try {
                                      			sleep(500); // attente d'une 1/2 seconde
                                  		} catch (InterruptedException ex) {
                                 			throw new RuntimeException(e);
                                  		}
			}
		}
	}

(en espérant ne pas me planter dans les "}")

05/01/2015, 20h49
adiGuba
Citation:

Envoyé par ChPr

adiGuba, j'ai mis en œuvre ta solution : ça fonctionne très bien. cependant quelques questions.
lorsque je me déconnecte, le throw new RuntimeException(e); me fait planter mon application, je l'ai remplacé par ne rien faire : ça marche.

Surement parce que tu fermes le flux. C'est pas top de "ne rien faire" car si un jour tu as un bug d'I/O tu ne t'en apercevras pas.

Il faudrait surtout savoir comment est ouvert/fermé le flux, mais on ne voit rien dans le code que tu donnes.

Le flux est utilisé uniquement dans le thread ?
Dans ce cas il serait peut-être préférable de gérer son ouverture/fermeture dans le thread...

Citation:

Envoyé par ChPr

Je n'ai pas bien compris le fonctionnement de ton thread. Dans celui du départ, grâce à la boucle while(true), on ne sortait jamais du thread ; c'est ce qui en causait la grosse consommation.

Non ce qui causait la grosse consommation c'est que tu n'effectuais pas d'opération bloquante : ton code vérifie constamment s'il y a des données à lire avec available().
En utilisant read() directement, le thread s'endort lorsqu'il n'y a rien à lire...

C'est comme deux gosses à l'arrière d'une voiture :
- Le premier demande toutes les 2 secondes "on est arrivé ?".
- Le second s'endard et attend qu'on le réveille un fois arrivé.
Citation:

Envoyé par ChPr

Dans ce que tu proposes, si k <= 0 on sort de la boucle.

Oui... mais si k<0 cela signifie que le flux est vide, et il n'y aura plus rien à lire.
Il est alors inutile de continuer à lire les données puisqu'il n'y en aura plus.

Citation:

Envoyé par ChPr

Je n'ai pas pu le vérifier, mais alors, que se passe-t-il ? qui relance le thread ?

Personne. J'ai considéré que le flux était "infini".
S'il a une fin et qu'il faut le lancer il faudra le gérer, mais c'est la même chose pour ton code, sauf que lui il continuera de vérifier qu'il n'y a "rien" 80000 par seconde...

Citation:

Envoyé par ChPr

Question annexe : mon message fait entre quelques caractères et environ 500 caractères. Quelle est la taille la mieux adaptée à prendre pour le buffer ?

512 ? 1024 ?
Franchement aucune idée, mais si les données ne sont pas trop grande il est préférable de prendre un buffer pouvant les contenir d'un coup.

Tes données sont envoyés ligne par ligne ?
Dans ce cas le plus simple serait d'utiliser un BufferedReader et readLine()...

Citation:

Envoyé par Népomucène

On en revient à la boucle while et au sleep(500)

Pourquoi le sleep(500) ? read() endort déjà le thread si besoin et le réveille au plus tôt.
Cela ne fait que rajouter un délai de 500ms inutilement...

a++
06/01/2015, 03h39
nicroman

Je ne rappelerait qu'une chose qu'un grand bonhomme de Java m'a une fois dite:

On ne devrait jamais avoir à utiliser "sleep()"... si on utilise sleep dans un code, c'est qu'on a oublié un élément de synchronisation (Object.wait() / Object.signal() ) ou qu'on a omis de passer par des fonctions bloquantes.

Le throw new RuntimeException() ne sert à rien.... "InterruptedException" indique qu'on doit s'arrêter (le thread doit mourrir) donc il faut sortir !

C'est intéressant ce sujet, je n'avais pas encore regardé la "blocabilité" d'un Inputstream.

@adiGuba tu suggères le code suivant (voir plus haut) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 @Override public void run() { try { byte buffer[] = new byte[100]; int k; while ((k = receiveStream.read(buffer, 0, 100)) > 0) { String data = new String(buffer, 0, k); Message msg = handler.obtainMessage(); Bundle b = new Bundle(); b.putString("receivedData", data); msg.setData(b); handler.sendMessage(msg); } } catch (IOException e) { throw new RuntimeException(e); } }
Je n'ai pas l'impression que le Thread va être bloqué sur la ligne while ((k = receiveStream.read(buffer, 0, 100)) > 0)
Il me semble que k va recevoir une valeur dans tous les cas : le nombre de bytes ou -1 s'il n'y a plus rien à lire.

Donc, à ce stade, le Thread se termine toujours et n'est pas relancé (tu as d'ailleurs suggéré dans le post suivant qu'il fallait le faire).
J'ai donc proposé de mettre le code dans une boucle qui me semblait plus simple que de recréer le Thread 2 fois par secondes.
Et comme il ne faut pas que ça tourne 80.000 fois par seconde, il m'a aussi semblé plus simple d'ajouter sleep(500).

Naturellement, je serai très intéressé par un meilleurs code que sleep(500).
Par ailleurs, ce que je connais ne concerne que java "classique". Je ne sais pas comment réagit java "Android".

06/01/2015, 14h33
adiGuba

Citation:

Envoyé par Népomucène

Je n'ai pas l'impression que le Thread va être bloqué sur la ligne while ((k = receiveStream.read(buffer, 0, 100)) > 0)
Il me semble que k va recevoir une valeur dans tous les cas : le nombre de bytes ou -1 s'il n'y a plus rien à lire.

Tu te trompe sur -1 : il n'est pas retourné s'il n'y a pas de données à lire, mais uniquement si on atteint la fin du flux (généralement cela signifie que le flux a été fermé de l'autre coté).
S'il n'y a rien à lire dans le flux (la source n'a pas encore écrit de données), alors read() bloquera et endormira le thread courant jusqu'à la réception des données.

Du coup la boucle que j'ai donné fait parfaitement l'affaire. read() bloquera le thread courant jusqu'à recevoir des données.

Citation:

Envoyé par Népomucène

Donc, à ce stade, le Thread se termine toujours et n'est pas relancé (tu as d'ailleurs suggéré dans le post suivant qu'il fallait le faire).
J'ai donc proposé de mettre le code dans une boucle qui me semblait plus simple que de recréer le Thread 2 fois par secondes.
Et comme il ne faut pas que ça tourne 80.000 fois par seconde, il m'a aussi semblé plus simple d'ajouter sleep(500).

Non le thread se termine uniquement si le flux est fermé.
Et si c'est le cas cela ne sert à rien de le maintenir en vie car en toute logique read() renverra toujours -1.
Dans ton cas ton thread va continuer à tourner indéfiniment pour rien car il ne devrait plus recevoir de données.

Après je ne sais pas si cela peut survenir ou pas (je ne connais pas la source du flux), mais si cela arrive il faut fermer le flux et en ouvrir un autre.
Mais en l'état le thread n'a pas les moyen de le faire, car ce n'est pas lui qui ouvre le flux.

:arrow: tu te compliques la vie avec des problèmes qui n'existent pas.

a++
06/01/2015, 14h49
tchize_

Citation:

Envoyé par nicroman

On ne devrait jamais avoir à utiliser "sleep()"... si on utilise sleep dans un code, c'est qu'on a oublié un élément de synchronisation (Object.wait() / Object.signal() ) ou qu'on a omis de passer par des fonctions bloquantes.

Hey! le sleep est bien pratique dans un unit test. Contrairement à un élément bloquant, on est sur que le travail reprend après X secondes. Alors qu'avec un synchro, si elle échoue (c'est un unit test, c'est sensé trouver les cas où ça échoue), c'est le serveur d'intégration continue qui est bloqué :mrgreen:

Puis ça me laisse le temps de lire les fenêtres ouvertes par le test unitaire :aie:
06/01/2015, 14h59
Népomucène

Citation:

Envoyé par adiGuba

Tu te trompe sur -1 : il n'est pas retourné s'il n'y a pas de données à lire, mais uniquement si on atteint la fin du flux

C'est en effet ce que dit la doc.

ChPr a écrit : C'est un ensemble de phrases NMEA qui se répètent toutes les secondes
Du coup il faudrait qu'il fasse un test pour savoir si entre deux envois, le Stream est fermé ou non.
06/01/2015, 18h25
adiGuba

Si le flux est fermé, aucun des codes postés ne pourra marcher...

a++

Citation:

Envoyé par Népomucène

... Du coup il faudrait qu'il fasse un test pour savoir si entre deux envois, le Stream est fermé ou non.

J'ai mis du temps à répondre car j'ai voulu analyser ce fameux "stream".

La configuration : un GPS blueTooth "GlobalSat BT-821C" et mon smartPhone "Samsung Galaxy S2".

Dans la boucle du thread, j'ai inclus l'enregistrement de la variable "data" à chaque passage. J'ai fixé mon buffer à 512. Selon que j'utilise la méthode avec le "sleep" ou l'autre, j'ai des résultats "instantanés" différents, mais au global, le fonctionnement est la même.
Code:

1 2 3 String data = new String(buffer, 0, k); // ci-après, une instruction qui enregistre le nombre d'octets "k", la date du système et les données "data" du buffer FCH.ecrit(String.format("%d - ", k)+GPS.getDate(System.currentTimeMillis(), "dd-MMM-yy HH:mm:ss")+" "+data, fchBT);
Ce que je vois au travers du fichier de données :

Lorsque mon GPS et le smartphone sont proches, il y a un flux ininterrompu de données.
Si j'éloigne le GPS du smartphone de telle manière qu'il ne soit plus à portée de réception pour une dizaine de secondes, le flux existe toujours et si je reviens dans l'espace de réception, le flux reste ininterrompu.
Si maintenant, je m'éloigne assez longtemps, environ une vingtaine de secondes, alors le flux s’interrompt. Si dés lors, je me rapproche du smartphone, dans une méthode comme dans l'autre, le flux ne reprend pas pas.

Je pense qu'il se passe ce qui suit :

au bout d'un certain temps, le "système BlueTooth" doit se dire que le liaison est perdue et qu'il faut la réinitialiser. Ce qui se traduit par :

pour la méthode avec le sleep : on ne sort pas du thread (boucle while(true)), mais il n'y a plus rien à recevoir : il faut réinitialiser le tout,
pour l'autre méthode, dès lors que le buffer interne du "BlueTooth" du smartphone est vide, on sort du thread. Comme il n'y a rien pour le faire repartir et que de toute façon, à une poignée de secondes de différence entre le moment où le buffer est vide et celui ou la liaison radio est rompue, la liaison est rompue, il faut réinitialiser le tout.

La différence de fonctionnement entre les deux méthodes :

avec le sleep : pratiquement, à chaque passage dans le thread, le buffer comprend un grand nombre d’octets, on va dire 300 en moyenne,
avec l'autre méthode, le nombre d'octets transmis est beaucoup plus saucissonné. Avec cette méthode, lorsque je me déconnecte où que la liaison est perdue, je passe par la case "exception" ???

Si cela vous intéresse , je peut vous joindre un fichier où figurent les enregistrements.

Cordialement.

Pierre

07/01/2015, 00h43
ChPr
Je constate que ce que tu proposes fonctionne parfaitement. Pour autant, j'avoue ne toujours pas comprendre.

Citation:

Envoyé par adiGuba

... En utilisant read() directement, le thread s'endort lorsqu'il n'y a rien à lire...

Que veut dire "rien à lire" ? si je lis l'instruction suivante :
Code:

1 2 while ((k = receiveStream.read(buffer, 0, 512)) > 0) { ...
pour moi, "rien à lire" veut dire que k <= 0 parce que le buffer est vide et dès lors, je sors de la boucle puis je sors du thread. Je ne vois pas ce que veut dire "le thread s'endort" ?

D'ailleurs, tu le confirmes en disant :

Citation:

Envoyé par adiGuba

... Oui... mais si k<0 (moi, j'avais écrit k <= 0) cela signifie que le flux est vide, et il n'y aura plus rien à lire.
Il est alors inutile de continuer à lire les données puisqu'il n'y en aura plus. ...

... ??? ...

Je crois que je viens de comprendre. peut-être vas-tu me confirmer ou m'infirmer ce que je crois comprendre :

la notion de flux et de contenu du flux sont deux choses différentes. Un flux peut exister avec un contenu "nul" et l'instruction "read" constatant que le flux existe mais qu'il n'offre aucune donnée attend patiemment qu'il y en ait. "read" renverra -1 lorsque le "flux" et non pas son contenu n'existera plus. J'ai bon ?

Cordialement.

Pierre
07/01/2015, 10h16
Népomucène

@ChPr : merci de ton retour, c'est intéressant de savoir "pour de vrai" comment se comporte ce flux.

Je serai aussi très intéressé par le code que tu vas utiliser finalement.
07/01/2015, 10h29
tchize_

Citation:

Envoyé par ChPr

la notion de flux et de contenu du flux sont deux choses différentes. Un flux peut exister avec un contenu "nul" et l'instruction "read" constatant que le flux existe mais qu'il n'offre aucune donnée attend patiemment qu'il y en ait. "read" renverra -1 lorsque le "flux" et non pas son contenu n'existera plus. J'ai bon ?

Oui, exactment. Le contenu, ça va, ça vient, y en a pas tout le temps. Par exemple sur une socket réseau, en général y a rien, de temps en temps, y a des données :)
La classe Stream, elle, encapsule la liaison entre les deux points. read renvoie -1 quand cette liaison est coupée, sinon renvoie ce qu'il peut et, accessoirement, peux bloquer si il n'y a rien à lire.
07/01/2015, 11h23
ChPr
Merci "tchize_" de confirmer ce que je dis à propos de la notion de flux utilisé ici. Ce qui a généré mon incompréhension est que, en physique, le flux n'est pas le conteneur, mais le contenu.

A la lumière de cela, je reconsidère ce que j'ai analysé :

dans une méthode comme dans l'autre, ce n'est pas lorsqu'il n'y a plus de données à transmettre que le fonctionnement s'arrête, c'est quand le système "BlueTooth" comprend que sa liaison radio n'est pas récupérable et que donc il "coupe" son flux.
- dans la méthode avec "sleep", on reste dans le thread, mais il n'est pas récupérable. C'est en me déconnectant que je sors du thread.
- dans l'autre méthode, c'est la cessation du flux qui entraîne la sortie du thread par une exception.
Cordialement.

Pierre
07/01/2015, 11h29
ChPr

Citation:

Envoyé par Népomucène

@ChPr : merci de ton retour, c'est intéressant de savoir "pour de vrai" comment se comporte ce flux.

Je serai aussi très intéressé par le code que tu vas utiliser finalement.

A la lumière de ce que j'ai découvert et appris, je vais utiliser la méthode proposée par adiGuba.

Pour autant, je retiens le "sleep()" car, comme le dis "tchize_", c'est une procédure non bloquante et qui peut avoir son intérêt dans d'autres cas.

Cordialement.

Pierre
07/01/2015, 14h06
adiGuba
Citation:
Envoyé par ChPr

au bout d'un certain temps, le "système BlueTooth" doit se dire que le liaison est perdue et qu'il faut la réinitialiser. Ce qui se traduit par :

pour la méthode avec le sleep : on ne sort pas du thread (boucle while(true)), mais il n'y a plus rien à recevoir : il faut réinitialiser le tout,
pour l'autre méthode, dès lors que le buffer interne du "BlueTooth" du smartphone est vide, on sort du thread. Comme il n'y a rien pour le faire repartir et que de toute façon, à une poignée de secondes de différence entre le moment où le buffer est vide et celui ou la liaison radio est rompue, la liaison est rompue, il faut réinitialiser le tout.
Oui c'est bien ce que je disais : cela ne sert à rien de maintenir le thread en vie puisque le flux est fermé et ne recevra plus rien.

Si cela peut se produire pendant l'application, il serait préférable de gérer l'ouverture/fermeture du flux dans le thread lui-même. Ainsi il pourra le fermer et le reouvrir selon le besoin.
Citation:
Envoyé par ChPr

avec le sleep : pratiquement, à chaque passage dans le thread, le buffer comprend un grand nombre d’octets, on va dire 300 en moyenne,
avec l'autre méthode, le nombre d'octets transmis est beaucoup plus saucissonné. Avec cette méthode, lorsque je me déconnecte où que la liaison est perdue, je passe par la case "exception" ???
Normal : dans le premier cas ton thread ne lis les données que toutes les 500ms. Elles ont donc le temps de s'accumuler (et read() tentera d'en lire le maximum).
Dans le second cas tu lis les données dès qu'elles arrivent, et donc petit à petit si le flux est discontinu et selon la connexion réseau.

Citation:

Envoyé par ChPr

la notion de flux et de contenu du flux sont deux choses différentes. Un flux peut exister avec un contenu "nul" et l'instruction "read" constatant que le flux existe mais qu'il n'offre aucune donnée attend patiemment qu'il y en ait. "read" renverra -1 lorsque le "flux" et non pas son contenu n'existera plus. J'ai bon ?

Oui c'est çà.
Si le flux est fermé read() renverra toujours -1 car on a atteint le fin du flux (il ne peut plus y avoir de données). Le flux est généralement fermé explicitement de l'autre coté (par le GPS dans ton cas), mais selon le tpe de communication cela peut également être fermé si la connexion se perd (ca dépend du flux car certains pourraient générer une exception dans ce cas).

Par flux vide je veux dire qu'il n'y a encore rien à lire dedans. Il peut y avoir de multiples raisons à cela (le GPS n'a pas encore écrit de données, latence dû à la connexion réseau, etc.).
Dans ce cas là le read() va bloquer jusqu'à recevoir des données. En effet read() ne renvoi jamais 0 (sauf si tu lui passe un buffer vide, mais c'est inutile).
Il bloquera toujours jusqu'à recevoir des données et renvoyer un résultat > 0 tant que le flux n'est pas fermé.

a++
07/01/2015, 14h13
tchize_

Il me semble que les socket configurée explicitement en non blocking ont un read qui retourne 0 si rien n'est disponible :p
07/01/2015, 15h01
ChPr

Je vous remercie tous :D pour vos interventions qui m'ont permis à la fois de mieux comprendre le fonctionnement des flux et de réduire la consommation de mon application.

Cordialement.

Pierre
07/01/2015, 15h29
adiGuba

Citation:

Envoyé par tchize_

Il me semble que les socket configurée explicitement en non blocking ont un read qui retourne 0 si rien n'est disponible :p

Je peux me tromper mais il me semble que les InputStream sont bloquant, et qu'il faut passer par les SocketChannel pour travailler en non-bloquant.

Enfin le fait est qu'en mode bloquant read() ne renvoi jamais zéro.

a++
07/01/2015, 15h35
ChPr

Citation:

Envoyé par adiGuba

... Si cela peut se produire pendant l'application, il serait préférable de gérer l'ouverture/fermeture du flux dans le thread lui-même. Ainsi il pourra le fermer et le reouvrir selon le besoin. ...

Je pense que cela ne va pas être simple et que par ailleurs, cela n'apportera rien dans le cas de mon application.

A l'allumage du GPS, un voyant m'indique qu'il est en communication "potentielle" avec mon smartphone. Cela veut dire que l'un et l'autre se sont détectés et donc la distance les séparant est correcte pour la transmission.

Pour l'ouverture du flux : je connecte le "socket" puis je lance le thread. Dès lors un voyant m'indique que le flux est ouvert et que les données sont transmises. Comme pour l'exploitation, la distance entre les deux appareils est toujours faible (soit sur moi, soit dans mon sac à dos posé à côté de moi), le problème de distance ne se pose pas.

Pour la fermeture du flux : c'est moi qui la gère dès lors que je n'ai plus besoin des informations du GPS. Je déconnecte le socket et j'éteins le GPS et le smartphone.

Cordialement.

Pierre