2013-12-16 8 views
6

Ich habe ein paar Tutorials zu lesen, wie mit Gleichzeitigkeit im Play beschäftigen und fand einige Beispiele:Concurrency in Play 2.1 oder höher

Asynchronous Job

import scala.concurrent.{ExecutionContext, future} 

def sendEmailAsync(from: String, to: String, subject: String, body: String) = { 
    import ExecutionContext.Implicits.global // in scala.concurrent 

    future { 
    EmailHelper.sendEmail(from, to, subject, body) 
    } 
} 

Geplanter Auftrag

Nun, ich bin ein bisschen verwirrt ... das erste Beispiel verwendet scala.concurrent.ExecutionContext.Implicits.global während der zweites Beispiel verwendet play.api.libs.concurrent.Execution.Implicits.defaultContext. Warum? Könnte mir jemand erklären, was hinter der Szene vor sich geht?

+0

Der 'ExecutingContext' war so etwas wie der ExecutorService (Thread Pool) von Java, man kann ihn sogar selbst erstellen, wenn man möchte. Zum Beispiel verwendet das Play-Slick-Modul einen getrennten Kontext, um db-Operationen auszuführen. https://github.com/freechh/play-slick/blob/master/src/main/scala/play/api/db/slick/SlickExecutionContext.scala – jilen

Antwort

3

Scala verwendet eine ExecutionContext für einige asynchrone Dinge (Futures, Promises). Ein ExecutionContext kann als ein Thread-Pool betrachtet werden, in dem Runnables für die Ausführung in einem der Threads eingereicht werden kann. (Es ist nicht unbedingt immer ein Thread-Pool, aber es ist in der Regel).

Die Art, wie der ExecutionContext verwendet wird, besteht normalerweise darin, das Argument als implicit an die Funktion zu übergeben, die es verwenden würde. Sie werden oft Methodensignaturen wie diese:

def doAsyncThings(args: Args)(implicit exc: ExecutionContext): Future[Result] 

Die „doAsyncThings“ Methode wird die implizite exc verwenden, die in übergeben wird Arbeit auf einem separaten Thread zu setzen.

Zur Beantwortung Ihrer Frage sind die Implicits Importe aus den beiden Beispielen implizite ExecutionContext-Instanzen, die zum Aufrufen der Methoden future und scheduleOnce erforderlich sind. Für explorative Zwecke spielt es keine Rolle, welche Sie verwenden. Die global eine aus der Scala-Bibliothek enthält (Iirc) einen Thread-Pool mit 8 oder so Threads. Ich würde vermuten, dass das Spiel ähnlich ist. Wenn Sie nicht besonders darauf achten, welche Threads funktionieren, sollte die Auswahl Sie nicht beeinflussen.

-2

Ich würde vermuten, der Unterschied kommt von "10 Sekunden". die Fähigkeit, Zeiten wie Zeiten zu benennen, ist nicht in die Sprache eingebaut. "Sekunden" wird implizit in DurationInt konvertiert.

+0

Das hat nichts mit dem Dispatcher zu tun, es kommt aus dem ' scala.concurrent.duration._' Import. – Ryan