哪個更適合從 C++、文件描述符上的 write() 或 FILE 上的 fprintf() 寫入敏感日志文件？

Question

我的理解是write()是一個系統調用，非常慢。 （這幾乎就像一種進程間通信。）任何與FILE一起工作的東西都會被緩沖，並且每 512 個字節或你有什么系統調用一次。 所以速度方面的FILE應該快得多。

但是，如果您有一條日志消息，然后是導致核心轉儲的內容，那么我不知道操作系統可以通過該機制 go 挖掘FILE的緩沖區並將其寫入磁盤。 因此，您很容易丟失日志文件的最后 5-10 行。 對於像金融軟件這樣的軟件，錯誤可能會花費數十億美元，而且您不希望任何錯誤出現兩次，因此需要大量的日志記錄，那就太糟糕了。

至少這是 25 年前的立場。 我很好奇這些天情況是否發生了變化？ 例如，是否有一種機制讓操作系統告訴標准 C 庫即使在 SEGV 或其他東西之后刷新 output 緩沖區？ 如果是這樣，那么FILE突然看起來好多了：速度沒有可靠性。 Plauger 在他 1992 年關於標准 C 庫的書中提到，理論上 write() 也可以是某種緩沖的 function，而不是系統調用。

部分問題是：Windows 或 Linux 上是否有任何編譯選項會影響這種權衡？ 例如，不僅僅是-O2 ，還有在核心轉儲時實際影響緩沖區刷新的選項？

這不是關於什么是允許的理論問題，而是關於今天和即將推出的 Linux 和 Windows 的實際問題。 雖然我知道有問題的各種標准將 promise 某種或其他級別的可靠性或性能，但通常這些標准被削弱到無用的地步，因為它們試圖涵蓋罕見的情況，例如 C 解釋器或在 80 年代 Cray 上運行的代碼，或者其他的東西。 此外，雖然我可以（並且正在）自己測試這個，但我的問題比今天的軟件給我的默認編譯選項要廣泛一些。

Answer 1

事情沒有改變。 CRT 和 OS kernel 仍然是獨立的王國。 並且沒有這樣的選項會影響這一點。 你必須用特殊的方式照顧好自己。 提示：查看 memory 映射文件。