Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.python > #5108
| 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-24 12:41 +0100 |
| Message-ID | <mailman.57.1516794080.2752.python-de@python.org> (permalink) |
| References | (10 earlier) <slrnp631j9.501.hjp-usenet3@hrunkner.hjp.at> <12101652-ad84-1456-63e2-5cc97372abea@mail.de> <mailman.151.1516378163.2620.python-de@python.org> <slrnp660s0.a6j.hjp-usenet3@hrunkner.hjp.at> <6fd0b424-54bb-cb84-db64-bb3a800f5d1e@mail.de> |
On 20.01.2018 09:53, Peter J. Holzer wrote: > Also einen HTTP-Client bzw. Proxy (nach außen soll er HTTP sprechen, zur > Applikation (möglicherweise) etwas anderes). Den Socket hatte ich nur deswegen im Kopf, weil ich mich mit select.select gut auskenne. Der Daemon würde das notify von Progress lesen, die URL in einen HTTP-Request einpacken und diesen dann auf einen HTTP-Socket schreiben. Dann kann der HTTP-Socket seine DNS und andere blockierende Operationen ausführen, aber der Socket, von dem der Daemon lesen würde, würde eben leer sein. Wo wir gerade darüber reden, fällt mir natürlich auf, dass die Verknüpfung von Request zu Response ein Problem sein könnte. Da bräuchte man dann wohl mehrere Socket-Paare, oder Header-Field-Matching. > Und weil oben schon das Stichwort Proxy gefallen ist: Was spricht > dagegen einen solchen Procy mit den Features, die Du haben willst, du > schreiben? Ich hoffe doch, dass so etwas wie ein Proxy bereits existiert. ;-) >> Die andere Seite (nämlich das NOTIFY von PostgreSQL) ist genau so >> einfach. 1 Socket, von dem man liest. > Hmm? Auf dem Socket musst Du aber das PostgreSQL-Protokoll sprechen. Ich > nehme an, dafür verwendest Du psycopg2 und hast das nicht selbst > implementiert? Natürlich. HTTP- oder PostgreSQL-Protokoll wäre natürlich durch eine Bibliothek gekapselt. So etwas macht man heutzutage eigentlich nicht mehr selbst. Das Protokoll ist ja auch gar nicht das Problem. Solche Sockets müsste man prinzipiell haben, damit man nach dem üblichen Verfahren mit select/epoll arbeiten kann. > Das scheint mir jetzt nicht sonderlich > event-loop-freundlich zu sein. Wenn Du nur NOTIFY brauchst, ok. Und > einfache Querys gehen auch noch (dürften aber schon etwas komplexer > sein). Aber sobald Du Transaktionen brauchst, hast Du (laut Manual) > verloren. Freilich, das wäre ja auch bei einem Daemon dieser Natur nicht wirklich von Nöten. > Da würde mich interessieren, wie das mit async/await aussieht: Laut > Manual gibt es "Support for coroutine libraries", aber das ist recht > vage und asyncio wird nicht mal erwähnt. Hat jemand damit praktische > Erfahrungen? Meinst du async/await oder asyncio? Referenzierst du http://initd.org/psycopg/docs/advanced.html#asynchronous-support und http://initd.org/psycopg/docs/advanced.html#support-for-coroutine-libraries? Dort sieht man wie man async ohne asyncio machen kann, indem man die Loop selbst schreibt, was jetzt ehrlich gesagt nicht wirklich kompliziert ist while True: select .... Asynchronous != coroutine, ersteres geht nämlich auch ohne zweiteres. ;-) Sven
Back to de.comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Diez B. Roggisch" <deets@web.de> - 2018-01-16 11:38 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-01-16 21:52 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Diez B. Roggisch" <deets@web.de> - 2018-01-16 22:24 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-01-19 06:47 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-19 17:09 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-01-20 09:53 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-24 12:41 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) Achim Domma <domma@procoders.net> - 2018-01-16 22:24 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) Wolfgang Strobl <news4@mystrobl.de> - 2018-01-18 07:06 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-17 18:32 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-17 18:48 +0100
csiph-web