4 ms·
This is for latency sensitive applications, where you're counting cycles and can't possibly afford to write nicely formatted log messages to a file. (Or can't r
by jsnell 11y ago
This is for latency sensitive applications, where you're counting cycles and can't possibly afford to write nicely formatted log messages to a file. (Or can't really even afford system calls in the main loop).
So there's a main application process, which does its logging by adding messages to the shared memory ring buffer, with a message format that's designed to be compact and cheap to write. And then there's going to be a reader which reads the log messages, and actually does something with them (filter, format, write to log files, whatever).
- amelius 11y agoCan't the logging be handled by a different thread, which subsequently writes the log entries to a file? This is how most loggers work I suppose (keep the main thread free from logging-work as much as possible). And because you use threads instead of processes, you get shared memory for free.
- jasonwatkinspdx 11y agoThis is not a replacement for an application logger or syslog or the like. This is for sampling traces of extremely high throughput and low latency networking systems built atop snabb.
- dang 11y agoYou may be right, but please don't make the criticism personal ("you're just not getting it", "while failing to understand", etc.) It makes the thread worse and typically provokes worse yet.
- jasonwatkinspdx 11y agoI edited my comment to reflect your criticism, but I disagree with it. It's pretty clear the person I was replying to just didn't even read the original posting.
- dang 11y agoAssuming that's true, you still shouldn't be personally abrasive in HN comments. Being right doesn't make it ok; it often makes it worse.
- vardump 11y ago> 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.