3 ms·

>>> POSIX I/O is stateful >> This is fundamental to the authorization model. Authorization happens at file open time. It's also what enables the stream abstrac

>>> POSIX I/O is stateful >> This is fundamental to the authorization model. Authorization happens at file open time. It's also what enables the stream abstraction. > This is very true, but in the workloads the author is talking about, there are often times that a stateless API would enable a more efficient implementation. Think about what is going on in your file server when you have 100k clients all accessing the same open file. Kernel can already cache such checks, I suppose. If you open a file 100k for 100k users you definitely have other scaling problems to solve first. Even if that becomes a bottleneck, a simple userspace LRU can solve the problem. I don't understand how having the permission check performed upon every operation is faster than performing it only once at open.

heavenlyblue 9y ago
But you don't need to keep the state of "this file is opened". What if the task that is being processed is idempotently writing something to the disk and then fails (and we assume we should be able to repeat it)? Statefulness would make us write the code to process the closure of the file and also to process all of the failures if we failed to close the file for proper RAII.
- dullgiulio 9y ago
  You don't keep the state "this file is opened", the kernel does. All you have is a ticket, the file descriptor. The problem is that the bookkeeping also includes the position in the file. I guess an API with a position argument could work, when you can leave it null for network operation (or unseekable file streams). But again, this does not make the API completely stateless and for good performance reasons.