On 28 Dec 2013 at 12:12, Bjorn Reese wrote:
I'm struggling to see the merit in such an approach - it would be incredibly verbose and complex to write even simple solutions, because i/o on files is not like sockets, *especially* that you almost never must strongly order i/o across a sequence of multiple sockets, but that is a very common case with files e.g. during ACID.
First, it follows a pattern that is familiar to Asio users. So rather than you being the only one who can write applications on top of Afio,
:) The current API design really is very easy to program against once you get used to thinking about i/o in that way. I find it very "natural" to write, though like with most C++ writing many more lines of source usually equals better quality code. I do wish C++ weren't like that, but there it is.
you get a broader community who are already familiar with the callback approach.
Understood. And I did try during AFIO design review to replicate ASIO's API identically, until I realised that wasn't wise, purely because of improved familiarity with the user base, and besides libuv uses ASIO style callbacks.
Second, you can more easily combine it with Asio socket code to create compound services that mixes socket and file access. For instance, a peer-to-peer file distribution mechanism.
Can I clarify something so? Where you stated:
I am thinking about an API that uses handles that looks more like Asio sockets. Write ordering can be handled, not by batching operations together, but rather calling the next write operation from the callback of the previous operation (Asio-style.)
By "calling the next write operation", I'm thinking that you're thinking that a kernel API ought to be issued right there and then yes just like ASIO does?
As much as this sort of operation dependency graph based design works well for its niche, I agree there is a swathe of code which ends up looking like the find in files implementation, and for that hopefully fibers will make look much more sane.
I am not arguing against the current API. Instead, I am arguing for the addition of a more familiar Asio-style callback API. I have no trouble with a fiber-enchanced API (similar to Asio with coroutines.)
Oh sure. But we'll test your assumptions about how file i/o works in practice first. If they're the same as mine, I think I'll come to understand exactly what you're looking for, and then I can implement it. Thanks for the feedback Bjorn. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/