Re: [boost] [afio] AFIO review postponed till Monday

Subject: Re: [boost] [afio] AFIO review postponed till Monday
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-21 22:43:29

On 21 Jul 2015 at 21:51, Glen Fernandes wrote:

> > The NT kernel API is exceptionally stable as any changes to it 
cost
> > Microsoft and anyone who writes device drivers dearly.
> 
> Even when I worked at Microsoft (not that long ago; I left in 
2014), in
> the teams/orgs I was in, we wouldn't even consider using any
> undocumented NT APIs in our code: What you're doing is brave. I'm
> suprised no AFIO users (if people are already using AFIO) have 
quoted an
> old post like
> http://blogs.msdn.com/b/oldnewthing/archive/2005/07/01/434648.aspx 
after
> seeing you use those APIs.

Sorry, I didn't see you originally said "undocumented APIs". It's 
like 3am
here :)

AFIO doesn't use any undocumented APIs nor behaviours. All the kernel 
APIs
it uses are from the official Microsoft kernel documentation e.g. 
here is
the docs for NtCreateFile
https://msdn.microsoft.com/en-us/library/windows/hardware/ff566424(v=v
s.85
). aspx.

The link you quoted is where someone was using truly undocumented
structure layouts which suddenly changed. That isn't a problem with 
the
official and fully documented NT kernel API.

If I said undocumented APIs anywhere in the AFIO docs, please do tell 
me
where.

> > What your comment has made me realise is that it would make much 
more
> > sense if there were a "normal persons tutorial" and an "advanced 
users
> > tutorial" where the former is a nice hand holding all-portable 
baby
> > steps thing, and the latter is stuff like writing distributed 
mutual
> > exclusion algorithms solely via atomic append onto the filesystem 
like
> > is in the current tutorial. How does that plan sound?
> 
> It's your library, and you know your target audience. I would only
> suggest you consider that for any given example that you have
> decorated with platform-specific code / conditional code to 
illustrate
> some point or the other, just make sure it passes the test that any 
real
> potential customer of AFIO is going to issue: "Could I implement 
what
> this example is trying to achieve using much less [perhaps
> platform-specific] code, and achieve the same level of 
performance?". If
> the answer is "no", then you have nothing to worry about.

Really with async file i/o it's always more a question of control 
rather
than performance. In the naïve case performance will usually be 
higher by
going synchronous.

The last section in the current tutorial demonstrates this: your 
naïve
algorithm which is great with a warm cache can perform extremely 
poorly on
a cold cache hard drive. AFIO lets you more easily tune your 
algorithm
through trial and error to work well in both cold and warm cache
scenarios, and moreover to do so portably.

That was its original use case. Now with the race free filesystem 
extensions, and given there is absolutely no portable reusable 
library I
am aware of which abstract those across platforms anywhere at all, 
things
have changed. If you were wanting to write portable code capable of
working under a changing filesystem you get no choice but AFIO right 
now
in any language (that I am aware of).

I think I should be presenting at CppCon about the race freedom 
stuff.
Right now I'm between jobs, so I may have to cancel Seattle if my new
employer requires it :(

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/