Logging-Klasse für Multithreading-Apps
-
Hi,
die klassischen "Logger" gibt's ja zuhauf, d.h. man kann aus dem Programm raus wichtige Kommentare in eine Datei schreiben, damit man im Remotefall noch Hinweise zu Problemen bekommt.
Unter dem Kontext Multithreading ist das aber hinreichend unbefriedigend, da man in jedem Thread getrennt loggen muß... sonst mixt der Logger ja alle Zeilen durcheinander, da parallel.
Wie wäre es mit der Vorstellung einer Loggerklasse, die für jeden Thread eine eigene Datei erzeugt und das auch ohne große Parametrierung automatisch erkennt und richtig macht? D.h. je nach Kontext des Aufrufers wird immer in der richtigen Thread-Datei gelockt?
-
Den Sinn verstehe ich nicht. Entweder mache ich Eventgesteuertes (mit IO-Completion-Ports vielleicht), dann wandert mein Ablauffaden, den ich gerade lesend verfolgen will, bei jeder IO-Operation in eine andere Datei. Oder ich starte pro Anfrage einen Thread, dann bekomme ich am Tag 3 Millionen Dateien.
Aber Logging an sich ist was spannendes. Und im Forum gibt es immer wieder tolle Ideen dazu. Per Pipe in anderen Prozess loggen, der nicht mitabkackt. Bringt mächtig Speed (weil nicht immer .close() oder .flush()) und Sicherheit. Per Netzwerk auf anderen Rechner loggen, wie vorhin nur extrem. Stream-Syntax benutzen log()<<time(0)<<": Anfrage von"<<ip<<'\n';. Ausmachbar machen, wobei auch der time-Aufruf verschwindigen muß, LOG(time(0)<<": Anfrage von"<<ip<<'\n') und warum das dann mit Kommas im Makro-Aufruf so schwierig ist. Was müßte log() tricksen, damit das log gelockt wird? boost nehmen, winapi, beides?
-
Nehmen wir einen Threadpool mit 10+ Threads. Jeder Thread übernimmt immer wieder andere Aufgaben, behält aber seine ID.
Für jeden neuen Job einen neuen Thread zu initiieren würde da viele Dateien erzeugen, ist doch ohnehin wg des Overheads nicht so oft zu finden.
Aber selbst wenn, dann braucht man noch einen Datenentität, die den "Workflow" kennzeichnet - alle gemeinsamen Workflows schreiben in die gleiche ID. Analog zum Konzept der Tasks in .NET 4.0.
-
Eine Logging-API wurde erst vor kurzem in boost aufgenommen. Wuerde mich wundern, wenn diese nicht mit mehreren Threads zurecht kommt.
-
Mir geht es ja auch mehr um die Frage, wie man im Multithreading-Umfeld loggen sollte. Was man dazu nimmt ist ja ein unterlagertes Thema.
-
wäre ne tolle Idee ^^