Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
On 2018-01-16 21:24, Diez B. Roggisch <deets@web.de> wrote:
Am 16.01.2018 um 21:52 schrieb Peter J. Holzer <hjp-usenet3@hjp.at>:
On 2018-01-16 10:38, Diez B. Roggisch <deets@web.de> wrote:
Sockets sind meiner Meinung nach ein viel besseres Abstraktionsniveau als meinen Quellcode überall mit diesem dämlichen async und await zu spicken.
Das einzige, was hier fehlt, wäre ein spezieller Typ von File-Deskriptor, der entsprechend in der Lage ist HTTP zu sprechen.
Du moechtest also einen HTTP-Server in den Kernel verlagern?
Gab es bei Linux schon.
Und hat NGINX und Apache erfolgreich verdrängt wie wir jeden Tag sehen.
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.)
Wo wir dabei sind, gleich noch ne RDBMS-engine?
War das nicht für Windows 2000 geplant?
Weiß nicht genau was du meinst. Das nie erschienene WinFS für Longhorn? Das war jedenfalls eher eine Desktop-Suche
Ja, aber meiner Erinnerung nach war das deutlich mehr als nur eine Desktop-Suche.
wie Spotlight, und zumindest letzteres ist über Worker im Userspace implementiert.
Man kann jedes Feature im Userspace oder im Kernel implementieren. NFS-Server sind traditionell im Kernel implementiert, aber die erste Linux-Implementation war im Userspace. Der SMB-Server ist unter Linux im User-Space implementiert (Samba), bei Windows bin ich mir nicht sicher, aber glaube, das ist im Kernel (was jetzt immer bei Windows genau der Kernel ist). Microkernel-Betriebssysteme lagern praktisch alles, was man in der Unix-Welt als Aufgabe des Betriebssystems sieht (Filesysteme, Memory-Management, sogar Scheduling) in den Userspace aus.
Strukturierte Files waren in den 70ern durchaus üblich. Unix war da mit seinem radikalen Minimalismus eher die Ausnahme.
Haben die beliebige Abfragen und Aggregationen über ihre Felder erlaubt? Sonst finde ich den Vergleich etwas weit hergeholt.
Das haben die meisten Datenbanken damals auch nicht.
*Kooperatives Multitasking ist einfach nur Schrott.* Ich habe mich neulich mit einem Mitt-Fünziger unterhalten, der asyncio in seinem neusten Projekt einsetzt, und habe ihn gefragt, wie er es findet und ob es sich irgendwie zu kooperativen Multitasking aus Mainframe-Zeiten (was bekanntlich aus der Mode gekommen ist) unterscheidet.
Er sagte folgendes:
naaa it’s the same thing .. like a loop u know .. marketing .. blah blah .. some technology went out from window .. and back from doors .. like something new *we call that progress* .. but is something like reinvent the wheel for sell something ;) ppl need “new” words, “new” languages .. to feel young :-)
“”” Alter Mann erklaert Technologie, die nach seiner eigenen Sturm-und-Drang-Phase entwickelt wurde, fuer ueberfluessig.
Eher umgekehrt. Alter Mann erkennt, dass die Technologie, die da als "neu entwickelt" angepriesen wird, schon in seiner Jugend nicht mehr neu war.
Wenn der alte Mann kooperatives Multitasking mit asynchroner Programmierung auf einem ansonsten immer noch präemptiven OS gleichsetzt, bleibe ich da eher bei meiner Sichtweise...
Du kannst natürlich jede Dir genehme Sichtweise auf Leute haben, die Du gar nicht kennst (ich kenne den alten Mann, von dem da die Rede ist, auch nicht). Du könntest aber auch annehmen, dass jemand, der ein bisschen Erfahrung hat, in der Lage ist, Ähnlichkeiten zwischen verschiedenen Systemen, die er im Lauf der Zeit kennengelernt hat, zu erkennen. hp -- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
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
participants (2)
-
Peter J. Holzer
-
Sven R. Kunze