> Jesus, why? You start the fsync in a thread and you wait for it to be completed
> with the HTTP response. Until this happens, the main thread can service other
> requests.
> Have you ever seen an async program which uses threads to run blocking
> operations?

The point was that it's odd that you are going to "trust" the userland daemon to finish the sync operation (which obviously has the possibility to fail) in some background thread while not trusting the OS/kernel to do the buffer/vm/pagecache flush at some "later" / "better" time (which you can even finetune to do it immediately - vm.dirty_ratio / vm.dirty_expire_centisecs etc).

Besides even with sync you don't get 100% of guarantees that the write actually ends (correctly) "on the iron" - coming from the land of ZFS ("lots of cheksuming") people will confirm that there are quite a few parts (like drive cache/firmware, controller cache/firmware) which occasionally lie about state of things.



p.s. then again nginx is also an opensource project and one can implement/propose whatever changes you need for your application even they don't align with authors (for example I also use nginx's webdav module but I do remove everything related to directory delete (to be more safe) just because of the way the app operates)


Just my 2 cents ..

rr

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx