A cross-platform file change monitor with multiple backends: Apple OS X File System Events, *BSD kqueue, Solaris/Illumos File Events Notification, Linux inotify, Microsoft Windows and a stat()-based backend.
Thanks for your great work. The API design, that user only need to register a callback function to a session and then fswatch handle the events dispatching and memory collection, is very convenient.
But in some case, we need a somehow not so convenient API interface that can expose the internal event loop so we can take control of it.
For example, suppose we want to get events from epoll and fswatch at same time, if there's such an API in fswatch, say, "fsw_wait_monitor" that will return when there are some events occur. We just need to create a new thread to invoke a function, in which fsw_wait_monitor and write(to a pipe one byte to notify the epoll) is invoked sequentially, in this way, fswatch event loop is integrated to the main epoll event loop in a maintainable way.
But with the callback facility, we can't control the occurrence of the callback function in another thread, it can occur before I've finished the work in current loop step. I just give an example working with epoll, it's an atomic system level API, with some more complicated event loop, e.g. gtk event loop, lwt or async user thread library, the callback facility will be more error-prone(since the callback can occur when the user thread library is in internal schedule stage that we even can't safely invoke the notification functions provided by the user thread library).
Hi, dear fswatch developers!
Thanks for your great work. The API design, that user only need to register a callback function to a session and then fswatch handle the events dispatching and memory collection, is very convenient.
But in some case, we need a somehow not so convenient API interface that can expose the internal event loop so we can take control of it.
For example, suppose we want to get events from epoll and fswatch at same time, if there's such an API in fswatch, say, "fsw_wait_monitor" that will return when there are some events occur. We just need to create a new thread to invoke a function, in which fsw_wait_monitor and write(to a pipe one byte to notify the epoll) is invoked sequentially, in this way, fswatch event loop is integrated to the main epoll event loop in a maintainable way.
But with the callback facility, we can't control the occurrence of the callback function in another thread, it can occur before I've finished the work in current loop step. I just give an example working with epoll, it's an atomic system level API, with some more complicated event loop, e.g. gtk event loop, lwt or async user thread library, the callback facility will be more error-prone(since the callback can occur when the user thread library is in internal schedule stage that we even can't safely invoke the notification functions provided by the user thread library).