fswatch is a cross-platform file change monitor currently
supporting the following backends:
ReadDirectoryChangesWfunction and reads change events asynchronously.
statcan be used.
The first releases of
fswatch were monolithic,
self-contained binaries whose output was typically piped to other
applications for processing. Given the nature of the features
fswatch, however, we recognized the need to
expose this functionality through a library and the libfswatch
package was born.
fswatch is now built upon it and all its
functionality is provided by the libfswatch library, with the
exception perhaps of some formatting routines printing results to the
The biggest issue we have faced while developing
abstracting the behaviour of different backends behind a common
interface and libfswatch is the result of that effort. Instead
of using different APIs, a programmer can use just one: the
API of libfswatch. The advantages of using
libfswatch are many:
libfswatch is a C++ library with C bindings which makes it available to a wide range of programming languages. If a programming language has C bindings, then libfswatch can be used from it. The C binding provides all the functionality provided by the C++ implementation and it can be used as a fallback solution when the C++ API cannot be used.
fswatch uses functionality provided by
libfswatch and depends on it, libfswatch is currently a
package nested into
fswatch. If either component is
updated, the whole package is, as well as their version numbers are.
From the GNU Build System point of view, the package version
of libfswatch is always kept in sync with
The library API version, however, is not, and it is
the only piece of information that should be kept into account when
linking against libfswatch. Since we use
build libfswatch, we adopt
scheme for library interface versions.
libtool’s versioning scheme
libtool’s versioning scheme is described by three integers:
currentis the most recent interface number implemented by the library.
revisionis the implementation number of the current interface.
ageis the difference between the newest and the oldest interface that the library implements.
The C API is built on top of the C++ API but the two are very different, to reflect the fundamental differences between the two languages.
The C++ API centres on the concept of monitor, a
class of objects modelling the functionality of the file monitoring
API. Different monitor types are modelled as different
classes inheriting from the
fsw::monitor abstract class, that
is the type that defines the core monitoring API.
API clients can pick the current platform’s default monitor,
or choose a specific implementation amongst the available ones,
configure it and run it. When running, a monitor gathers file
system change events and communicates them back to the caller using a
The C API, on the other hand, centres on the concept of
monitoring session. A session internally wraps a monitor
instance and represents an opaque C bridge to the C++ monitor
API. Sessions are identified by a session handle and
they can be thought as a sort of C ‘façade’ of the C++ monitor
class. In fact there is an evident similarity between the C library
functions operating on a monitoring session and the methods of the
The C++ API does not deal with thread safety explicitly. Rather, it leaves the responsibility of implementing a thread-safe use of the library to the callers. The C++ implementation has been designed in order to:
As a consequence, it is not thread-safe to access a monitor’s member, be it a method or a field, from different threads concurrently. The easiest way to implement thread-safety when using libfswatch, therefore, is segregating access to each monitor instance from a different thread.
The C API, a layer above the C++ API, has been designed in order to provide the same basic guarantee:
There is an additional limitation which affects the C library only:
the C binding implementation internally uses C++11 classes
and keywords to provide the aforementioned guarantees. If compiler or
library support is not found when building libfswatch the
library will still build, but those guarantees will not be
honoured. A warning such as the following will appear in
configure’s output to inform the user:
configure: WARNING: libfswatch is not thread-safe because the current combination of compiler and libraries do not support the thread_local storage specifier.
If you find problems or have suggestions about this program or this
manual, please report them as new issues in the official GitHub
https://github.com/emcrisostomo/fswatch. Please, read the
CONTRIBUTING.md file for detailed instructions on how to