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

From	Stefan Behnel <python-de@behnel.de>
Newsgroups	de.comp.lang.python
Subject	Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
Date	2018-01-23 06:29 +0100
Message-ID	<mailman.30.1516685386.2752.python-de@python.org> (permalink)
References	(9 earlier) <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> <b7c58b04-4bf4-3340-5b37-4c9a11520681@behnel.de>

Show all headers | View raw

Sven R. Kunze schrieb am 22.01.2018 um 17:14:
> 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?

Etwas vereinfacht und in Punkt 2) fehlt noch ein "beispielsweise", aber ja,
kann mensch so sagen.


> 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.

Doch, denn genau das war ja der Aufmacher für diese Diskussion. Es lohnt
sich oft, einen wie auch immer existierenden (async-)Steuerprozess durch
asyncio zu ersetzen, weil dadurch ein ganzer Haufen wiederverwendbarer Code
verfügbar wird.

Du hast von einem sync/async Zwei-Welten-Problem gesprochen, aber das
wirkliche Problem war die Zersplitterung innerhalb der async-Welt. Das ist
das, was asyncio beseitigt.

Stefan

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

Thread

Re: [Python-de] select.epoll() vs async framework (PostgreSQL) Stefan Behnel <python-de@behnel.de> - 2018-01-23 06:29 +0100

csiph-web