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
> > 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
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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk