Autor Thema: [erledigt] IPC - Callback Funktion registrieren  (Gelesen 24977 mal)

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #40 am: 04. July 2010, 10:28 »
Hm, mit readahead habe ich noch nicht gemacht, aber bist du dir sicher? Die Manpage sagt nämlich:

Zitat von: Linux Programmer's Manual: readahead(2)
readahead() blocks until the specified data has been read.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #41 am: 04. July 2010, 12:07 »
Hallo,


Wenn du Dateizugriffe multiplexen willst, kann es schon sinnvoll sein; beispielsweise liest du von einer modernen SSD mit ordentlich Datenrate und einer antiken Festplatte je ein GB. Für Schreiben gilt entsprechendes, für Sockets ebenfalls.
Das ist dann aber klassisches asynchrones I/O, man initiierst mehrere Jobs und schaut wie weit die jeweils sind um immer an der wichtigsten Stelle (non-blocking) zu arbeiten. Aber gerade dieses select() würde im Szenario mit den Dateien von unterschiedlich schnellen HDDs nichts helfen, wenn ich das richtig verstanden habe prüft select() nur ob noch Bytes da sind (was bei Dateien wo der aktuelle File-Pointer noch nicht am Ende der Datei ist ja immer stimmt), bei Sockets kommen von außen immer wieder mal neue Bytes dazu im Gegensatz zu Dateien die nicht einfach so von alleine wachsen.

Übrigens skaliert unter Linux ein fork()-basierter Webserver besser als ein auf poll() basierender
Bis zu wie vielen gleichzeitigen Anfragen? Ich denke mal spätestens beim 100000-ten fork() hast Du auch auf nem dicken Server Probleme. Klar ist fork() relativ kostengünstig (wobei ich hoffe auf meiner segmentierten Plattform das CreateThread() deutlich billiger zu bekommen) aber man braucht trotzdem einiges an Speicher (für die vielen Stacks und Verwaltungsstrukturen).


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #42 am: 05. July 2010, 18:40 »
Hm, mit readahead habe ich noch nicht gemacht, aber bist du dir sicher? Die Manpage sagt nämlich:

Zitat von: Linux Programmer's Manual: readahead(2)
readahead() blocks until the specified data has been read.
Akzeptiert, dann geht das in der Form nicht. Müsste man dann selbst implementieren. :-)

Aber gerade dieses select() würde im Szenario mit den Dateien von unterschiedlich schnellen HDDs nichts helfen, wenn ich das richtig verstanden habe prüft select() nur ob noch Bytes da sind (was bei Dateien wo der aktuelle File-Pointer noch nicht am Ende der Datei ist ja immer stimmt), bei Sockets kommen von außen immer wieder mal neue Bytes dazu im Gegensatz zu Dateien die nicht einfach so von alleine wachsen.
Korrekt, allerdings könnte man ja ein Flag dazu verwenden.
Grundgedanke ist halt, dafür einen Thread zu basteln, der im Hintergrund die benötigten Daten liefert.

Übrigens skaliert unter Linux ein fork()-basierter Webserver besser als ein auf poll() basierender
Bis zu wie vielen gleichzeitigen Anfragen? Ich denke mal spätestens beim 100000-ten fork() hast Du auch auf nem dicken Server Probleme. Klar ist fork() relativ kostengünstig (wobei ich hoffe auf meiner segmentierten Plattform das CreateThread() deutlich billiger zu bekommen) aber man braucht trotzdem einiges an Speicher (für die vielen Stacks und Verwaltungsstrukturen).
Ich beziehe mich auf diese PDF, die ist allerdings von 2003. Der Kernel hat Threading noch nicht so lange, das wurde ewig in der glibc implementiert, von daher ist die Ansage nicht mehr ganz aktuell.

;-)

Gruß,
Svenska

 

Einloggen