Re: [boost] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-09-01 18:53:21

On 31 Aug 2015 at 20:47, Vladimir Prus wrote:

> > I would doubt that AFIO will ever be useful for this situation. The
> > way in which it will lock byte ranges is incompatible with all other
> > Windows programs in order to achieve POSIX byte range locking
> > semantics (and therefore compatibility with AFIO's running on NFS or
> > CIFS). It is also, deliberately, incompatible with other programs
> > doing POSIX byte range locking too in order to prevent unexpected
> > interactions.
> 
> Could you clarify that? File locking, on Windows, that is incompatible
> with all other Windows programs, does not seem like a useful like locking
> to me.

Firstly, the byte range locking isn't finished nor turned on in AFIO 
right now, so I may yet change my mind.

However, right now if you specifically need local platform byte range 
locking, I think you need custom code using the native APIs to do 
that, and AFIO deliberately does not get in the way.

Windows and POSIX byte range locking is fundamentally completely 
incompatible. No single API which is sane can do both in a performant 
way.

> > AFIO combined with anything not speaking AFIO is not supported, nor
> > will be. You will probably find this unreasonable and not useful, but
> > such are the differences between the platforms in file system any
> > additional abstraction is not practically useful.
> 
> Sorry, are you saying that AFIO cannot work if other programs are touching
> the same files/directories? How that is potentially useful? If I control
> all parties that write to a particular tree, I can use either boost.interprocess,
> or boost.thread, to avoid all and every conflict at the filesystem locking.

I meant specifically byte range locking only. AFIO never locks byte 
ranges in the files other third party processes uses. It locks byte 
ranges in a hidden shadow file only which is managed by AFIO 
internally. AFIO on POSIX can talk to AFIO on Windows over networked 
drives using the hidden shadow file as a IPC channel.

> >> - Write content X to a file F, but only if the file content did not change
> >>     since a change to that file was reported to me.
> >
> > I would imagine tools other than AFIO would be more appropriate here.
> > For example, Boost.Filesystem.
> 
> Possibly, thought I'd generally prefer async operations.

I would be very surprised if async gained you anything except extra 
maintenance costs.

If, and only if, you very rarely open and close files and have a real 
async backend (i.e. currently Windows only) then you have a good 
change of seeing significant improved performance IF you restructure 
your filing system code to match how filing systems really work which 
means throwing out how most programmers write file system code. The 
resulting application will always be complex and non-trivial i.e. 
it's not worth the hassle for almost everybody.

Niall

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