2012-10-21 1 views
4

J'ai ce traitaccès à ExecutionContext

trait NonBlockingGoodness extends DataStore { 
    import akka.dispatch.{ Future, ExecutionContext } 
    import akka.util.duration._ 
    import akka.util.Timeout 

    implicit val ec = ExecutionContext.fromExecutorService(yourExecutorServiceGoesHere) 
    implicit lazy val timeout = Timeout(5 seconds)  
} 

Je voudrais accéder au ExecutionContext dans un autre trait comme tel

trait AsyncGoodness extends NonBlockingGoodness { 
    import akka.dispatch.Future 

    def doSomething = { 
    Future { "Future is the bomb." } 
    } 

Cependant, je reçois l'erreur

Could not find implicit value for parameter executor: akka.dispatch.ExecutionContext 

MISE À JOUR: J'ai compris h omment obtenir le ExecutionContext portée

trait AsyncGoodness extends NonBlockingGoodness { 
    import akka.dispatch.ExecutionContext 
    import akka.dispatch.Future 

    def doSomething()(implicit executor: ExecutionContext) = { 
    Future { "Future is the bomb." } 
    } 

Cependant, j'ai une question de suivi. Depuis que je peux avoir plus de 1 méthode en AsyncGoodness qui utilise ExecutionContext, est-il un moyen de le transmettre au niveau trait au lieu de chaque méthode comme je l'ai fait ci-dessus.

+0

Juste une remarque qui passe: votre nom NonBlockingGoodness implique que tout blocage est mauvais. C'est une croyance courante de nos jours mais elle est un peu naïve: les E/S non bloquantes peuvent être pires que les E/S bloquantes dans certains cas. D'autres problèmes, tels que l'excès de parallélisme et le fait d'avoir (ou non) des pools de threads bien réglés et même d'éviter le piège de la loi d'Amdahl, doivent être pris en considération. Voici une histoire de cas: http://www.bigbeeconsultants.co.uk/blog/dispatch-http-critique –

+1

Est-il suffisant qu'être non-bloquant soit bon dans le contexte où il l'utilise? Ou avez-vous considéré que le nom signifie simplement que ce trait fait du bien, et qu'il arrive juste à le faire non-bloquant? Qu'est-ce que c'est, Tumblr? – hoff2

Répondre

0

Comme il se trouve, tout ce que je dois faire est de spécifier explicitement ec type de retour pour le compilateur à l'utiliser. Voici le code de travail

trait NonBlockingGoodness extends DataStore { 
    import akka.dispatch.{ Future, ExecutionContext } 
    import akka.util.duration._ 
    import akka.util.Timeout 

    implicit val ec: ExecutionContext = ExecutionContext.fromExecutorService(yourExecutorServiceGoesHere) 
    implicit lazy val timeout = Timeout(5 seconds)  
} 

trait AsyncGoodness extends NonBlockingGoodness { 
    import akka.dispatch.Future 

    def doSomething = { 
    Future { "Future is the bomb." } 
    } 
1

Je sais que vous préférez ne pas avoir à importer quoi que ce soit de plus, mais quelque chose comme ça devrait marcher pour vous.

trait NonBlockingGoodness { 
    import scala.concurrent.{ Future, ExecutionContext } 
    import scala.concurrent.util.duration._ 
    import akka.util.Timeout 

    object Implicit { 
    implicit val ec = ExecutionContext.Implicits.global 
    implicit lazy val timeout = Timeout(5 seconds) 
    } 

} 

trait AsyncGoodness extends NonBlockingGoodness { 
    import scala.concurrent.Future 
    import Implicit._ 
    def doSomething = { 
    Future { "Future is the bomb." } 
    } 
} 
+0

Bob semble être sur Akka2.0, mais votre réponse n'est valide que pour Scala2.10. –

+0

Je sais que mes déclarations d'importation ne correspondent pas à ce qu'il utiliserait. Mais je pensais que le concept de base de "object Implicit {}" et "import Implicit._" fonctionne dans Scala 2.9. – cessationoftime

+0

Roland a raison, je suis sur Akka 2.0 – Bob