Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.python > #5106

Re: [Python-de] select.epoll() vs async framework (PostgreSQL)

From "Sven R. Kunze" <srkunze@mail.de>
Newsgroups de.comp.lang.python
Subject Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
Date 2018-01-22 17:14 +0100
Message-ID <mailman.21.1516637662.2752.python-de@python.org> (permalink)
References (8 earlier) <374d8f30-d5ec-a097-6bd0-ce15fc0d824e@mail.de> <fea78855-045d-377b-5acd-75de5dab4d18@behnel.de> <0f1b475c-3af3-9baa-860a-1d3baa57f8c3@sschwarzer.net> <b06f8eab-3acf-9191-e470-b0add12a3c33@behnel.de> <93975564-a6f2-6f0c-87f3-fc0d49b85c3f@mail.de>

Show all headers | View raw


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

Back to de.comp.lang.python | Previous | Next | Find similar


Thread

Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-22 17:14 +0100

csiph-web