On Tue, Aug 5, 2014 at 10:46 AM, Szymon Gatner wrote:

That is what I am not seeing, extensions will often require platform depended code anyway, like this directory monitor - has native Windows and POSIX calls.

True enough. But at the time there was a difference between us writing and maintaining platform dependent code verses that fact being hidden away in a third party library. So effectively our code would be write-once for all platforms and then the extension would hide away the details for each platform: theoretically reducing our time to market. Then if we had any particular issues, we had the option of either fixing it ourselves or contacting the original author for support. Or if it was egregious enough, we could look for another third party library. Only finally after exhausting those, would we look at writing platform dependent code ourselves. -- Keith Bennett

Hey Boris!

Please note that the directory monitor (it's from 2008) can be implemented much better today. For example, have a look at this implementation (from 2011): <https://github.com/boostcon/2011_presentations/blob/ master/wed/asio_extensions/directory_monitor.cpp>

thanks for answering. I actually saw both implementations (2008 ans 2011) and my question arose from differences from them. Version from 2011 is single class and NOT an ASIO extension - there is no deriving from basic_io_object or io_service::service. Hence my question: what is the benefit of deriving from those classes and making your class an ASIO extension vs 2011 version where io_service is just used "externally" for synchronization purposes.

2014-08-05 21:42 GMT+02:00 Boris Schäling :

On Tue, 05 Aug 2014 21:05:30 +0200, Szymon Gatner wrote:

[...]Version from 2011 is single class and NOT an ASIO extension - there

...

is no

deriving from basic_io_object or io_service::service. Hence my question: what is the benefit of deriving from those classes and making your class an ASIO extension vs 2011 version where io_service is just used "externally" for synchronization purposes.

I think the short answer is that you shouldn't derive from basic_io_object or create your own service unless you have to. :) [...] Today if you ever need to wait for events asynchronously, you can reuse windows::object_handle and can ignore the entire framework Boost.Asio set up for I/O objects.

Answer I was looking for, thanks a lot! Regards, Szymon Gatner

On 6 Aug 2014 at 0:17, Bjorn Reese wrote:

On 08/05/2014 03:36 PM, Szymon Gatner wrote:

...

I am going through code of directory monitor ASIO extension by Boris

You may also be interested in AFIO (F for file.) It has an experimental directory monitor living in some branch whose name I do not know.

https://github.com/BoostGSoC/boost.afio.git

Ah yes. The directory monitor isn't ready for production use. By production use I mean: * Can cope with 1m entry directories easily as the rest of AFIO can. * Can handle 50,000 entries changing every second in a 1m entry directory without losing change deltas and without racing on individual stats on a 2Ghz single core, with approximate linear scaling with additional cores i.e. four cores can monitor four 1m entry directories seeing 5% change. * Works as expected on remotely mounted filing systems like NFS. * Uses native OS features to avoid polling when possible. * Works reliably on Microsoft Windows (hard), Linux (slightly easier), BSD and OS X (easiest by far of the lot). Paul Kirth presented on this at C++ Now 2014. It is a surprisingly tough engineering problem, and requires a design approaching ideal for it to work at all. tl;dr; it'll be a while longer. Paul is still kicking at it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Sorry, I forgot (it's nearly 2am) to mention that AFIO itself is production ready and has been in the review queue since October 2013.

Why isn't it under review yet?

On 6 Aug 2014 at 8:58, Szymon Gatner wrote:

...

Ah yes. The directory monitor isn't ready for production use. By production use I mean:

* Can cope with 1m entry directories easily as the rest of AFIO can.

* Can handle 50,000 entries changing every second in a 1m entry directory without losing change deltas and without racing on individual stats on a 2Ghz single core, with approximate linear scaling with additional cores i.e. four cores can monitor four 1m entry directories seeing 5% change.

I should be OK :) What are the advantages over Boris' version tho?

Boris's won't deadlock as frequently as the AFIO one :). If code isn't in the master or stable branch in AFIO, I wouldn't use it. You could use AFIO's directory enumeration which is in stable combined with Boris' directory monitoring. It depends on if you need unracy metadata support on Windows as Filesystem is currently racy there.

...

Sorry, I forgot (it's nearly 2am) to mention that AFIO itself is production ready and has been in the review queue since October 2013.

Why isn't it under review yet?

There is a large backlog, some libraries have been waiting in the queue for years. Part of this is due to sickness in the Boost culture and the ongoing decline of Boost for two years now, part is simply because no one wants nor needs a portable asynchronous file i/o library and therefore no one is interested in volunteering as review manager. Besides, it wouldn't pass a review right now because its API would be considered unusable as it was designed for maximum speed, and therefore isn't "Boosty enough" - people would ask "where are the iterators?" etc etc. This is also because the API is designed as a stable binary ABI to be assembled by the forthcoming monadic continuations framework being led out by Vicente. Still, if you need maximum portable file i/o performance now, it works very well and will continue to work into the future. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/