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)

Path csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From "Sven R. Kunze" <srkunze@mail.de>
Newsgroups de.comp.lang.python
Subject Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
Date Mon, 22 Jan 2018 17:14:13 +0100
Lines 50
Message-ID <mailman.21.1516637662.2752.python-de@python.org> (permalink)
References <29ce1adc-0fea-e23c-e321-858e0d52dc1c@thomas-guettler.de> <a1669a00-b66c-6cce-8546-570a857e77aa@behnel.de> <71ab86cc-0e21-da2f-9577-8b6ccbe707ba@thomas-guettler.de> <2915505E-9237-40C4-A2BF-A4A22D00A216@web.de> <04ab7b73-e182-081c-74c7-976e3eac9b84@mail.de> <d1a40b67-1a37-7164-f980-85d473a0838e@behnel.de> <9ce770aa-b6dd-f709-1a95-f1e02f82f7f6@mail.de> <bc8618a5-2ffc-46eb-72a4-afa12ddc030d@behnel.de> <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>
Mime-Version 1.0
Content-Type text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding 8bit
X-Trace news.uni-berlin.de FPNQej9PX+PrqKkT1MyRtQSHCxtKTb9DJ3q6iKXapbMQ==
Return-Path <srkunze@mail.de>
X-Original-To python-de@python.org
Delivered-To python-de@mail.python.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/simple; d=mail.de; s=mailde201610; t=1516637654; bh=IZ23SD6VvXlStQflJBhKGSonSngc00Og9qEM0zchYDc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LIv25cepxg1iQfUBdDcHuU2iHnilveQlVCf6qQ0zQGwIxdbotQFNWHlmvVIHh1iL9 We8C7Qo6JaaOulvEMF5ONF+caspoAqmUVOjs15TlWOBWyFrPO+JSDxNLgrB1EmLIv9 grto+Xch3aVYmICuEv7hlfFn8IcbM53rZxRuKENo=
In-Reply-To <b06f8eab-3acf-9191-e470-b0add12a3c33@behnel.de>
Content-Language de-DE
X-BeenThere python-de@python.org
X-Mailman-Version 2.1.25
Precedence list
List-Id Die Deutsche Python Mailingliste <python-de.python.org>
List-Unsubscribe <https://mail.python.org/mailman/options/python-de>, <mailto:python-de-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-de/>
List-Post <mailto:python-de@python.org>
List-Help <mailto:python-de-request@python.org?subject=help>
List-Subscribe <https://mail.python.org/mailman/listinfo/python-de>, <mailto:python-de-request@python.org?subject=subscribe>
X-Mailman-Original-Message-ID <93975564-a6f2-6f0c-87f3-fc0d49b85c3f@mail.de>
X-Mailman-Original-References <29ce1adc-0fea-e23c-e321-858e0d52dc1c@thomas-guettler.de> <a1669a00-b66c-6cce-8546-570a857e77aa@behnel.de> <71ab86cc-0e21-da2f-9577-8b6ccbe707ba@thomas-guettler.de> <2915505E-9237-40C4-A2BF-A4A22D00A216@web.de> <04ab7b73-e182-081c-74c7-976e3eac9b84@mail.de> <d1a40b67-1a37-7164-f980-85d473a0838e@behnel.de> <9ce770aa-b6dd-f709-1a95-f1e02f82f7f6@mail.de> <bc8618a5-2ffc-46eb-72a4-afa12ddc030d@behnel.de> <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>
Xref csiph.com de.comp.lang.python:5106

Show key headers only | 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