2 ms·
I'm so glad this is being discussed. The intricate and weak durability guarantees, the unaddressed dangers of global mutable state (without reasonable locking c
by gue5t 10y ago
I'm so glad this is being discussed. The intricate and weak durability guarantees, the unaddressed dangers of global mutable state (without reasonable locking capabilities outside of "only ever write something so small the OS wouldn't ever decide to break it up"), and the inability to properly deal with files and the filesystem asynchronously are gaping holes in POSIX (and Linux) semantics.
Maybe we can actually get a powerful asynchronous IO API that allows the OS to schedule disk requests effectively and applications to avoid blocking in situations where they don't have to, while providing more guarantees about data durability and concurrency. It's undeniably possible, but it will require a level of coordination between parties (standardization and work from kernel hackers in Linux and other OSes, userspace libraries to expose new kernel functionality, applications switching over to use the libs) that I hadn't expected to see come together. Maybe these discussions will provide some impetus to get people working on all sides of the issue.
Anyone who hasn't read them should see the comments on previous discussion of this topic, which demonstrate how hairy this area is right now: https://news.ycombinator.com/item?id=11511269 https://news.ycombinator.com/item?id=11511269