Hm, mit readahead habe ich noch nicht gemacht, aber bist du dir sicher? Die Manpage sagt nämlich:
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