Clientsockets aus der vhlib
-
terraner schrieb:
volkard schrieb:
auch die haben nicht alles optimal gelöst
was z.b.?
mfghttp://www.c-plusplus.net/forum/viewtopic-var-t-is-117044-and-highlight-is-.html
falls dir dabei nicht übel wird, und du gar behaupten möchtest, das sei ideal, sollten wir einen thread zu dem thema aufmachen oder auch nicht.neuer thread sollte sein, wenn du nur mir mal widersprechen willst. wenn "boost ist ideal" sowas wie ein glaubensbekenntnis ist. oder wenn du ein troll bist.
alter thread sollte sein, wenn du mir in einem wort recht gibst oder wenn die folgende diskussion das hauptsächliche ziel hat, die vhlib derart zu verbessern, daß man *nicht* vector<shared_ptr<Mutterklasse*> > schreiben muss.
-
vhlib schrieb:
gibts zum thema sockets aus der vhlib noch was zu besprechen?
hoffe, die linuxifizierung der sockets bald fertig zu haben. und dann gibt's halt nen webserver, an dem viele dinge sind. und threads.
-
die vhlib wurde plötzlich krank und verstarb binnen tagen, nachdem sie bei der linuxifizierung der sockets vom rechten weg abgekommen war.
einen letzten blick auf sie kann man werfen unter http://volkard.de/tot.tar.bz2
aber ihre kleine tochter lebt http://volkard.de/vhlib.tar.bz2 und die zeichen stehen gut, daß sie die 50 files überschreiten könnte.
die neue geht davon aus, daß alle wichtigen sys-calls / api-calls im wesentlichen auf den system gleich sind (also linux ist auch nur ein windows) und wrapper mit gleicher schnittstelle angeboten werden sollten (diesmal sogar kostenlos).
-
Die Tocher ist ja voll klein??????
-
hast du überhaupt die leute vom forentreff gefragt ob du das einfach so als tot erklären darfst?
-
Was isn das für eine Lib ? Da sind doch nur 50 Dateien drin wo immer nur 2 Zeilen drin stehen
-
tot schrieb:
hast du überhaupt die leute vom forentreff gefragt ob du das einfach so als tot erklären darfst?
ich denke, wir sind uns da einig.
-
Malificius schrieb:
Was isn das für eine Lib ? Da sind doch nur 50 Dateien drin wo immer nur 2 Zeilen drin stehen
gell, schlimmes design. ich sollte kleinere dateien machen, damit es übersichtlicher wird. bin ja auf dem weg.
-
Der Weg ist das Ziel...
PS:
hello, wor
-
so wird die lib nie fertig
-
Malificius schrieb:
Was isn das für eine Lib ? Da sind doch nur 50 Dateien drin wo immer nur 2 Zeilen drin stehen
Versteh Ich da jetzt was falsch oder sollten da wirklich 50 Dateien drin sein? Bei mir sind nämlich nur 8 Dateien da.
die main, makefile, sysLinux(Impl), sysWindows(Impl) und sys(Impl).
-
in tot waren ca. 50 dateien. davon aber auch viele die von der ide erzeugt worden sind
-
dead is schrieb:
davon aber auch viele die von der ide erzeugt worden sind
doch nicht.
-
@volkard: kannste bitte support für i/o completition port einbauen für windows?
-
recv schrieb:
@volkard: kannste bitte support für i/o completition port einbauen für windows?
klar.
aber ich will nicht. ich weiß, daß synchrone IO das beste ist. bitte denke allein mal and die 16-kernigen prozessoren demnächst. ok, zur zeit 2 kerne. aber mehr kerne sind viel einfacher als mehr speed.
-
kein normaler user wird 16 kerne haben. auch nicht in 10 jahren.
-
man kann doch festlegen wieviel threads man haben will
-
recv schrieb:
kein normaler user wird 16 kerne haben. auch nicht in 10 jahren.
sein prozessor wird haben. warum? weil es geht.
-
Hi!
Soll die Library jetzt eigentlich nur für dich (für den Webserver) sein oder für die Allgemeinheit?
Wenns für die Allgemeinheit ist sollte es wohl ein bisschen flexibler sein.
-
netzwerkprogger schrieb:
Hi!
Soll die Library jetzt eigentlich nur für dich (für den Webserver) sein oder für die Allgemeinheit?
Wenns für die Allgemeinheit ist sollte es wohl ein bisschen flexibler sein.ich hab mich lange mit iocompletion ports rumgeschlagen. und ich weiß auch, wie verflix schnell die sind. und recht einfach auch noch.
sei doch mal so freundlich und gib ein statement ab zu
http://www.cs.ualberta.ca/~paullu/C498/events.bad.idea.vonbehren.pdf
ignorieren wir zudem die velen messungen auf 2.4-er kernels, denn da skalierten threads noch schlecht.und nu?
ein thread pro client ist eine feine sache. ich werde keine async-sockets coden, nur weil jemand das haben wollen könnte. ja, ich gehe sogar so weit, daß die files kein seek und tell haben werden, sondern nur streams sind. für eigene projekte werde ich die vhlib nehmen. hab ich auch schon für kleinigkeiten und es fühlte sich gut an.
naja, außerdem muss ich extreme abfahren, um sie zu testen. falls ich unrecht haben sollte, und ein thread pro client keine feine sache ist, so muß das doch mal einer nachweisen. wie anders, als daß man es ausprobiert? und falls ein client pro thread eine feine sache ist, werde ich bald den lighttd plattmachen und das nehmen wir dann auch als hinweis an.
gestern abend hat jemand den neuen code linuxifiziert, der die vhlib vorher noch nie gesehen hat. hat mit labern und so nur ne stunde gedauert. das nehme ich als hinweis, daß ich die system-abhängigkeiten jetzt richtig gekapselt habe.
und es ist anzunehmen, daß ein paar leute die vhlib auch mögen werden. so zwischen 3 und 10 wohl. sie sollte aber ein interessanter lesestoff sein (notizmach: muss ein buch drüber schreiben).
außerdem ist sie zur not ja auch noch erweiterbar und du kannst dir asnyc-sockets dazuschreiben. werde ich aber nicht, weil Vector und Array und Stack dann wichtiger sind. und dann ein memory allocator und files und direkteres cout und vielleicht regexp, vielleicht filemapping, threads, wie beende ich alle threads, die im recv oder accept hängen so, daß sie ihre objekte destruieren? ist dazu auf linux das signal EINTR geeignet? stoppt das alle blockierenden calls und läßt sie einen fehler zurückgeben?