berkus / dir_monitor Goto Github PK

The current implementation of monitor_operation::PostAndWait prevents the call to async_monitor_thread_.join(); in shutdown_service() from finishing. PostAndWait waits on a std::condition_variable that is never notified as the lambda handler is newer run after shutdown. This prevents the thread from ever finishing.

Either remove the waiting part, or possibly do something like

void PostAndWait(const boost::system::error_code ec, const dir_monitor_event& ev) const
        {
            std::mutex post_mutex;
            std::condition_variable post_condition_variable;
            bool post_cancel = false;

            this->io_service_.post(
                [&]
                {
                    handler_(ec, ev);
                    std::lock_guard<std::mutex> lock(post_mutex);
                    post_cancel = true;
                    post_condition_variable.notify_one();
                }
            );
            std::unique_lock<std::mutex> lock(post_mutex);
            while (!post_cancel)
            {
                post_condition_variable.wait_for(lock, std::chrono::milliseconds(1000));
                if(this->io_service_.stopped())
                    break;
            }
        }

If you take the example test program test_running.cpp and add a asio/signal_set handler to trap Ctrl-C there doesn't appear to be a way to remove the async_monitor operation thus io_service.run() never exits.

In my application our Ctrl-C handler gracefully tells all asio io_objects (timers, sockets) to "shutdown". Then the io_service exits once all the handlers have executed and the program drops out of the bottom of main.

Even calling remove_directory in the Ctrl-C handler appears to keep the work on the queue.

I encountered uncaught exceptions be thrown from boost::asio::basic_dir_monitor_serviceboost::asio::dir_monitor_impl::work_thread() Line 218 in Windows. As enlightened by this link, and study the the current implementation, work_thread() is running in its own thread, thus the exceptions being thrown cannot be caught from any other thread. Can you please confirm this is correct? If yes, I'd like to fix it as the above link suggest. I'll be better if you have test cases for exceptions.

I have directory structure like this:
dir1
|
+- dir2
After running remove_directory("dir1") events in "dir1" are not catched, but events in "dir2" continue to be catched. Is it a bug or feature?

line #255(\include\windows\basic_dir_monitor_service.hpp) throws error under windows as class dir_monitor_event has no constructor accepting 3 parameters. Deleting the first parameter will let go, but I do not know the impact without further understanding the internals.

@berkus
Working with this repository, I have encountered several times that codebase was in an invalid state.
For example look at the last fail situation: changes which were broken CI

My offer is to implement more safily workflov. Nothing complicated, just "master-develop" model.
As illustation: http://nvie.com/posts/a-successful-git-branching-model/#the-main-branches

1. all works should take a place at branch's of develop
2. all PR should be requested to develop branch. branching from master should be prohibited.
3. project owner sometimes merges to master. when there is confidence in the stability of the code.
   Also it would be nice to start project versioning.

This library has what I'm looking boost.asio approach and xplat support , but sadly no recent activity. Seems like it had good momentum but the PR's are 18 months old, which is quite a bummer. Please advise on 1.0's stability and the likelihood of revival.

Since the project is not actually part of ASIO, consider moving things to a separate namespace.

All the libraries I saw had their headers in a nested folder in include/.
It is done for making them available as <dir_monitor/dir_monitor.hpp>, for example.

Maybe, we should consider moving headers in a nested folder, too?

In all examples except windows you have your work_thread_ in the basic_dir_impl.hpp. In windows you have this inside of your basic_dir_monitor_service.hpp and only use your dir_monitor_impl.hpp to manage your containers such as:
boost::ptr_unordered_map<std::string, windows_handle> dirs_;

Is there an explicit reason for this?

Thank you!

Please, it's possible to add support for recursive monitoring? On Windows there is argument bWatchSubtree (see here), which is set to FALSE for now.

I'm using dir_monitor in a project and suddenly started getting linking errors once the project got bigger and the dir_monitor headers included in multiple places.
The main culprit was that helper::throw_system_error_if and helper::to_utf8 were getting defined multiple times.
Setting the two functions as inline seems to take care of this.

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.