Discussion :

[tchize_]

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.

[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

[ChPr]

@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

[adiGuba]

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 :

1. 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,
2. 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.

• 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.

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++

[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

[ChPr]

Je vous remercie tous 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

[adiGuba]

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++

[ChPr]

... 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