[Python-de] select.epoll() vs async framework (PostgreSQL)
Sven R. Kunze
srkunze at mail.de
Fr Jan 19 11:09:23 EST 2018
On 19.01.2018 06:47, Peter J. Holzer wrote:
> Nein, aber die Idee ist nicht so absurd, wie Du glaubst.
>
> (Abgesehen davon glaube ich nicht, dass Dein Vorposter das wollte. Für
> micht klingt das eher, als wollte er einen HTTP-Parser und/oder
> -Generator im Kernel haben (wobei mir nicht ganz klar ist, wozu) und
> sowas würde als Teil etwa einer Firewall- oder WebDAV-Komponente wenig
> Stirnrunzeln auslösen.)
Damit der konkrete Anwendungsfall klarer wird.
Aufgabe war/ist es URLs asynchron zu callen und den Rückgabewert in eine
DB zu schreiben (siehe erster Post dieses Threads).
Nun stellte sich leider heraus, dass eine URL zu requesten nicht
wirklich einfach ist. Die Lib "requests" auf jeden Fall ist ziemlich
blocking und insbesondere muss es mehrere blockierende Dinge
nacheinander tun. Im einfachsten Fall:
1) DNS lookup
2) open connection
3) push request data on socket
Meine naive Lösungsvorstellung war: ein Socket, der genau alles das
kann, was requests kann. Damit würde die select-loop extrem einfach
werden, und als Schleifen-Bauer kann man sich um die eigentlichen Dinge
kümmern.
Die andere Seite (nämlich das NOTIFY von PostgreSQL) ist genau so
einfach. 1 Socket, von dem man liest.
Sven
Mehr Informationen über die Mailingliste python-de