dir_monitor
dir_monitor copied to clipboard
Two dir_monitors on a single io_service
Well, I have tried to create two different dir_monitor instances (for different folders) on a single dir_monitor with a code like this:
#include <dir_monitor/dir_monitor.hpp>
#include <iostream>
struct moni {
moni(boost::asio::io_service& ios) : m1(ios), m2(ios) {}
boost::asio::dir_monitor m1, m2;
void m1_operation() {
std::cout << 1 << std::endl;
m1.async_monitor([this](boost::system::error_code ec, boost::asio::dir_monitor_event ev){
if(ec == boost::asio::error::operation_aborted) return;
std::cout << ev << std::endl;
m1_operation();
});
}
void m2_operation() {
std::cout << 2 << std::endl;
m2.async_monitor([this](boost::system::error_code ec, boost::asio::dir_monitor_event ev){
if(ec == boost::asio::error::operation_aborted) return;
std::cout << ev << std::endl;
m2_operation();
});
}
};
int main() {
boost::asio::io_service ios;
moni m(ios);
m.m1.add_directory("path_to_dir1");
m.m2.add_directory("path_to_dir2");
m.m1_operation();
m.m2_operation();
ios.run();
}
And I got something strange:
1
2
dir_monitor_event ADDED "/home/gamepad/Librevault/New Folder"
1
dir_monitor_event ADDED "/home/gamepad/Librevault2/New Folder (1)"
2
dir_monitor_event ADDED "/home/gamepad/Librevault/.librevault/librevault.db-journal"
1
dir_monitor_event ADDED "/home/gamepad/Librevault2/.librevault/librevault.db-journal"
2
dir_monitor_event MODIFIED "/home/gamepad/Librevault/.librevault/librevault.db-journal"
1
dir_monitor_event MODIFIED "/home/gamepad/Librevault2/.librevault/librevault.db-journal"
2
dir_monitor_event REMOVED "/home/gamepad/Librevault/.librevault/librevault.db-journal"
1
dir_monitor_event REMOVED "/home/gamepad/Librevault2/.librevault/librevault.db-journal"
2
The files were modified in a random order, but processed only in 1-2-1-2-1-2. If there were no changes in 1'st folder, then dir_monitor blocked and waited for changes in 1'st folder. 2'nd folder changes were processed only after the 1'st directory got some changes.
This is abnormal behavior for boost::asio. Btw, two dir_monitors on two separate io_services work fine. Tested with inotify and fsevents backends. Reproducible in 100% cases.
I am also seeing this behavior on Win7 Boost 1.60.
Two separate io_service threads require 2 separate threads no? You need to call .run on both and they both block.
Yes, in a general case, two io_services require two separate threads.
Is there any documentation on this project which provides some guidance on usage such as topics like this? The test cases are abstracted to the point that it's very difficult to see how it's intended to be used.
@solvingj no, only test cases. As for me, it was enought to understood how to use this library. All interfaces are very simple, so i don't know what to add.
I'm a novice C++ developer and had never used ASIO before, so I definitely want to share my perspective that the interfaces are not "very simple" objectively speaking. "Simple" and "Familiar to me" are often conflated ideas when people communicate about programming.
In addition to the concepts of ASIO being non-trivial and requiring extensive reading, the tests do unrelated gymnastics like this: dm.async_monitor(boost::bind(&create_file_handler, boost::ref(test_file1), _1, _2));
Which requires knowledge of boost::bind, and you have to dig through the tests and reverse engineer them to see what to do.
While documentation would help novices like me, it doesn't seem like this library is very active or supported. Thus, I completely understand that it doesn't have resources available to write documentation to make it approachable for novices. I think this is probably why many novice-to-intermediate developers turn to Poco Project, which places an emphasis on usable documentation without assuming pre-requisite knowledge. Different tools are just a better fit for different skill levels.
For the record, this is what blows me away about: https://github.com/nlohmann/json
Several simple yet real-world examples with explanations about how to use all the really cool features. If you wanted to know what to add... I would say that's the best model.
well,
firstly, this is not the issue of specific library if you don't know about bind
idiom.... this library bases on boost::asio
so obviously you should know something about.
secondly, you can use Poco
, but keep in mind that Poco's directory monitor realized (but may be something changed since my last Poco project review) as a stupid file iterating at regular time intervals and don't use OS events. if it acceptable for you - fine! but how would you know about it if you're really novices? documentation? only dig through Poco sources could help me.
thirdly, this library at my point of view was born as a result of specific and narrow engineering task. no more contributes - apparentlly, all tasks were solved....
at last, this is open-source project so just make pull request with your documentation)))))))))))))
ps your question а little does not correspond to this issue, why didh't you create a new?
Hi, if you are novice with ASIO I recommend going through Boost.Asio examples and working with that library in particular. dir_monitor
is a simple enough user of the existing ASIO infrastructure.
Adding some good examples is always good - I'll happily accept documentation PRs.
@sbelsky , Indeed, should have been a separate issue. Apologies.
@berkus This is the kind of positive response I was hoping for. Since you've said you're planning on continuing it's maintenance a bit, I feel much more comfortable using it.