Conception multi-threads ?
UniX
Membre
Salut.
Je vous expose la question que je me pose.
J'ai une appli qui communique avec un appareil via une liaison série, filaire ou bluetooth.
A l'heure actuelle, mon appli n'a qu'un thread. Les données récupérées depuis l'appareil sont traitées (des calculs à faire), puis, à la fin du traitement, je demande la mise à jour de la vue qui affiche tout ça avec setNeedsDisplay:YES.
Mais comme les données arrivent en permanence, visiblement la mise à jour de la vue n'est pas appellée, sauf quand je stoppe le processus de réception des données.
A partir de ce constat, dois-je envisager de mettre en place plusieurs threads, dont un ne fera que traiter les données reçues, et demander la mise à jour de la vue, mise à jour qui se fera dans le thread principal ? Est ce la bonne solution ?
Je vous expose la question que je me pose.
J'ai une appli qui communique avec un appareil via une liaison série, filaire ou bluetooth.
A l'heure actuelle, mon appli n'a qu'un thread. Les données récupérées depuis l'appareil sont traitées (des calculs à faire), puis, à la fin du traitement, je demande la mise à jour de la vue qui affiche tout ça avec setNeedsDisplay:YES.
Mais comme les données arrivent en permanence, visiblement la mise à jour de la vue n'est pas appellée, sauf quand je stoppe le processus de réception des données.
A partir de ce constat, dois-je envisager de mettre en place plusieurs threads, dont un ne fera que traiter les données reçues, et demander la mise à jour de la vue, mise à jour qui se fera dans le thread principal ? Est ce la bonne solution ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Par contre, il me semble me souvenir avoir lu quelque part que les classes relatives au bluetooth avaient un bug, et que ça ne fonctionnait pas si exécuté hors du thread principal, quelqu'un a des infos ?
http://lists.apple.com/archives/Bluetooth-dev/2004/Jul/msg00027.html
De plus, comme le bluetooth fonctionne par un système de callback, le multi-thread n'est pas vraiment utile...
Que veux-tu dire par "callback" ? Parceque je fais mes tests justement avec la liaison bluetooth, et le problème que je décris dans ce topic se produit avec le bluetooth.
pour une un canal série (IOBluetoothRFCOMMChannel), la méthode appelée quand des données sont reçus est:
- (void)rfcommChannelData:(IOBluetoothRFCOMMChannel*)rfcommChannel data:(void *)dataPointer length:(size_t)dataLength
Ceci se faisant de manière asynchrone, il n'y a pas de blocage et tu dois pouvoir mettre à jour ton interface au fur et à mesure que les données arrivent.
En revanche il ne m'a pas semblé que ça fonctionnait. J'ai tracé l'exécution : la méthode rfcommChannelData: data: length: est appellée en permanence, et la fin de cette méthode, je demande la mise à jour de la vue, mais la méthode drawRect de la vue n'est pas lancée, on repart sur rfcommChannelData: data: length:
En fait, elle ne se lance que lorsque je ferme le port série, lors de la dernière execution de rfcommChannelData: data: length:
Bon, pour être sûr de tout ça, je vais faire quelques tests de plus.
Au lieu de faire setNeedsDisplay, essaye display, ça devrait forcer l'affichage. Mais faire attention, il se peut que tu perdes des données si la mise à jour de l'interface prend trop de temps, à tester donc...
J'y repars pour appronfondir un peu le truc ....
Je vais tester display également.
euh, une question un peu bête : depuis quand y a un port série sur les Mac ?
J'en ai jamais vu moi :-\\
Au tout début (et jusqu'à l'apparition des imacs), il y avait 2 ports série (sous forme de mini-din 8 broches). Le premier était traditionnelemnt dédié au modem ou à AppleTalk (icône téléhone) et le second à l'imprimante.
L'apparition des ports USB sur macs a entrainé la disparition de ces 2 prises.
Au niveau du système, les ports série existent toujours, même s'il ne sont pas présents physiquement. Cela permet d'utiliser très facilement des adaptateurs USB<->série dans driver particulier.
.
Merci de l'éclaircissement !