On 20.01.2018 13:37, Stefan Behnel wrote:
Stefan Schwarzer schrieb am 20.01.2018 um 00:02:
On 2018-01-19 11:17, Stefan Behnel wrote:
Dann rufst du statt "query.all()" eben "await background_query(query.all)" auf, und schon blockiert's nicht mehr und erlaubt gleichzeitig 'unbegrenzten' I/O-Durchsatz. er Absolut, hier ist die triviale Minimalversion:
""" size_of_connection_pool = config.get(...)
pool = ThreadPoolExecutor(max_workers=size_of_connection_pool)
def background_query(func, *args, **kwargs): return pool.submit(func, *args, **kwargs) """
Da wir nun endlich mal Quelltext haben, sieht die Welt schon etwas verständlicher aus. Um das jetzt zusammenzufassen: 1) es gibt einen Steuerprozess, der muss async sein und in dem läuft auch die Loop 2) blockierender Code ist inkompatibel, da nicht kooperativ, und wird in ThreadPools ausgelagert, wo er keinen Schaden anrichten kann Stimmt das soweit? Mit anderen Worten, wenn ich in den Projekten bereits einen Aufgaben-Verteiler-Prozess (Steuerprozess) habe, dann brauche ich mir um asyncio eigentlich keine Gedanken zu machen. Die Schleife hat schon jemand anderes programmiert, mein Zeug wird ausgelagert in Threads oder Prozesse, da diese nicht kooperativ sind (z.B. Apache WSGI). Also braucht nur derjenige asyncio, der auch diese Schleifen programmiert, um seine Schleife durch die EventLoop von asyncio eventuell abzulösen. Hatte ich vor asyncio keine Schleife, brauche ich jetzt auch kein asyncio, weil es keine Schleife abzulösen gibt. Und der Trick mit dem "unbegrenztem IO-Durchsatz" kommt durch den fehlenden Overhead mehrerer Prozesse/Threads, welcher in einer einfacher Liste im Steuerprozess effizienter abgebildet werden kann (durch die Queue im PoolExecutor). Sven