Scala acteurs thread control

Question

Je voudrais en savoir plus sur la mesure dans laquelle il est possible de contrôler où chaque acteur Scala est en cours d'exécution. Je suis dans un cas un peu particulier: une grande réactivité est souhaitée, une bonne partie du code est critique, et pire encore, je suis sur Android. Dans cet esprit, mon objectif principal est: rendre le code aussi lisible et simple que possible.

Ce que je voudrais idéalement pour atteindre (certains de ceux sembler déraisonnable/carrément stupide au premier abord, lisez les justifications ci-dessous)
- Je voudrais être en mesure de répondre à certains messages dans certains particulier, toujours le même, arbitraire thread, mais je n'ai pas besoin de le bloquer pour attendre les messages.
- Je souhaite que la majeure partie de mon traitement soit effectué sur un pool de threads de travail, idéalement en redimensionnement automatique comme les acteurs Scala, tout en garantissant que ce traitement n'aura jamais lieu sur le thread arbitraire ci-dessus. Ces exigences découlent d'une nécessité Android: le framework Android utilise un fil spécial pour toucher l'interface utilisateur, et si vous touchez un objet UI d'un autre thread, vous obtenez une exception. De cette façon, il applique une sorte de modèle thread/lock qui est exactement ce que j'essaie de contourner. Mais de toute façon, c'est comme cela: je dois assurer une partie de mon traitement, à savoir ce qui concerne les objets de l'interface utilisateur, fonctionne sur ce thread et pas d'autre, parce que le framework dit que c'est comme ça que je devrais le faire. Un effet secondaire ennuyeux de cela est tant que ce thread traite mon code, l'interface utilisateur cesse de mettre à jour et mon application cesse d'être sensible. Donc je dois m'assurer que ce thread ne soit pas choisi aléatoirement pour du code de longue durée que je pourrais avoir dans une certaine réaction {}, et idéalement qu'il ne traite jamais quelque chose qui pourrait aussi bien être fait par un autre thread. Le framework android fournit une classe appelée Handle, qui implémente une sorte de passage de message - vous lui envoyez un Runnable, et il s'exécutera sur le thread de l'interface utilisateur. Je peux l'utiliser si j'en ai besoin. Créer un exécutable à chaque fois encombre significativement le code - une chose qui peut être faite serait de l'encapsuler dans une méthode pour que je puisse écrire quelque chose comme
onUIThread {/ * du code * /}
... qui est beaucoup plus agréable que le nouveau Runnable() {def run() {}}. D'un autre côté, c'est essentiellement ce que la fonction onUIThread ferait, donc je créerais deux fermetures - et ensuite je devrais traiter les détails de l'allocation de mémoire pour les fermetures. Je dois le faire, car chaque fois que j'attribue un objet, le GC a une chance de courir et sur Android, ce qui est généralement une pause de 150ms, ce qui gâcherait mon expérience utilisateur si cela se produit dans un chemin d'exécution critique.

Donc à la fin:
- Dois-je aucune façon d'associer statiquement un acteur avec un fil, pour que je puisse avoir un acteur de l'interface utilisateur, réagir {} à l'intérieur et ont toujours son code exécuté sur le thread d'interface utilisateur ?/* Je sais que c'est une mauvaise conception en soi, lisez la logique ci-dessus pour voir pourquoi je ne peux pas l'aider */
- Dois-je un moyen de m'assurer que ce fil particulier ne sera jamais considéré pour répondre à un message dans un Réagir {}? - Des suggestions de ce que je pourrais faire, étant donné mes contraintes, pour obtenir une meilleure lisibilité du code?

Answer 1

Vous pouvez implémenter un planificateur client en étendant l'attribut IScheduler qui pousse les tâches sur le thread ui, puis remplacer la méthode du planificateur sur votre acteur qui doit s'exécuter sur le thread ui.

Quelqu'un a essayé cela avec swing un certain temps je et je pense qu'il a travaillé: http://scala-programming-language.1934581.n4.nabble.com/scala-Swing-event-thread-actors-td1987246.html

Alors, que les autres acteurs utilisent le planificateur normal.

Mais je ferai remarquer que la réaction {} aboutit à la création d'une fermeture qui est finalement enveloppée dans un exécutable. Il utilise également des exceptions pour le contrôle de flux, ce qui introduit des frais généraux considérables (je n'ai aucune idée de combien sur Dalvik). Donc, si la fermeture de GC'ing nuit vraiment à la performance de votre application, j'ai des doutes que les acteurs vous sauveront.