> Can't the logging be handled by a different thread, which subsequently writes the log entries to a file?... So what happens if the process crashes? All of th

> Can't the logging be handled by a different thread, which subsequently writes the log entries to a file?... So what happens if the process crashes? All of the most recent log messages are lost. Exactly those messages that are the most useful to figure out what went wrong. Well, I guess you can dig them out of a core (crash) dump... if you're lucky enough to have one. And what about I/O load. If you have multiple log files open, you're going to need to sync them separately too. Sync goes all the way to the physical device. Then you have the problem of putting the log messages from multiple files in temporal order. Please don't tell me you tell me you just use TSC timestamps to order them. Different CPUs can have TSCs running at different rates and starting from different offsets. So the order can be lost unless all processes are locked to same single CPU core. If you then plan to use a different timer than TSC, like ACPI or HPET, just forget about it. HPET timer takes a whole microsecond to read and ACPI timers are even slower. TSC can be read in a few nanoseconds. > And because you use threads instead of processes, you get shared memory for free. Actually the cost is exactly same. All memory is really "shared" memory, MMU just maps a page to some point in physical memory. Shared memory just means two processes have virtual page(s) mapped to same physical memory page(s). From the hardware point of view, both are exactly the same thing and thus exactly as fast.