AnyEvent-Filesys-Notify

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    watcher to monitor the "IO::KQueue" object.

    WARNING - IO::KQueue and the "kqueue()" system call require an open
    filehandle for every directory and file that is being watched. This
    makes it impossible to watch large directory structures (and inefficient
    to watch moderately sized directories). The use of the KQueue backend is
    discouraged.

  Fallback
    A simple scan of the watched directories at regular intervals. Sets up
    an "AnyEvent->timer" watcher which is executed every "interval" seconds
    (or fractions thereof). "interval" can be specified in the constructor
    to AnyEvent::Filesys::Notify and defaults to 2.0 seconds.

    This is a very inefficient implementation. Use one of the others if
    possible.

Why Another Module For File System Notifications
    At the time of writing there were several very nice modules that
    accomplish the task of watching files or directories and providing
    notifications about changes. Two of which offer a unified interface that
    work on any system: Filesys::Notify::Simple and File::ChangeNotify.

    AnyEvent::Filesys::Notify exists because I need a way to simply tie the
    functionality those modules provide into an event framework. Neither of
    the existing modules seem to work with well with an event loop.
    Filesys::Notify::Simple does not supply a non-blocking interface and
    File::ChangeNotify requires you to poll an method for new events. You
    could fork off a process to run Filesys::Notify::Simple and use an event
    handler to watch for notices from that child, or setup a timer to check
    File::ChangeNotify at regular intervals, but both of those approaches
    seem inefficient or overly complex. Particularly, since the underlying
    watcher implementations (Mac::FSEvents and Linux::INotify2) provide a
    filehandle that you can use and IO event to watch.

    This is not slight against the authors of those modules. Both are well
    respected, are certainly finer coders than I am, and built modules which
    are perfect for many situations. If one of their modules will work for
    you by all means use it, but if you are already using an event loop,
    this module may fit the bill.

README.md  view on Meta::CPAN

watcher to monitor the `IO::KQueue` object.

**WARNING** - [IO::KQueue](https://metacpan.org/pod/IO::KQueue) and the `kqueue()` system call require an open
filehandle for every directory and file that is being watched. This makes
it impossible to watch large directory structures (and inefficient to watch
moderately sized directories). The use of the KQueue backend is discouraged.

## Fallback

A simple scan of the watched directories at regular intervals. Sets up an
`AnyEvent->timer` watcher which is executed every `interval` seconds
(or fractions thereof). `interval` can be specified in the constructor to
[AnyEvent::Filesys::Notify](https://metacpan.org/pod/AnyEvent::Filesys::Notify) and defaults to 2.0 seconds.

This is a very inefficient implementation. Use one of the others if possible.

# Why Another Module For File System Notifications

At the time of writing there were several very nice modules that accomplish
the task of watching files or directories and providing notifications about
changes. Two of which offer a unified interface that work on any system:
[Filesys::Notify::Simple](https://metacpan.org/pod/Filesys::Notify::Simple) and [File::ChangeNotify](https://metacpan.org/pod/File::ChangeNotify).

[AnyEvent::Filesys::Notify](https://metacpan.org/pod/AnyEvent::Filesys::Notify) exists because I need a way to simply tie the
functionality those modules provide into an event framework. Neither of the
existing modules seem to work with well with an event loop.
[Filesys::Notify::Simple](https://metacpan.org/pod/Filesys::Notify::Simple) does not supply a non-blocking interface and
[File::ChangeNotify](https://metacpan.org/pod/File::ChangeNotify) requires you to poll an method for new events. You could
fork off a process to run [Filesys::Notify::Simple](https://metacpan.org/pod/Filesys::Notify::Simple) and use an event handler
to watch for notices from that child, or setup a timer to check
[File::ChangeNotify](https://metacpan.org/pod/File::ChangeNotify) at regular intervals, but both of those approaches seem
inefficient or overly complex. Particularly, since the underlying watcher
implementations ([Mac::FSEvents](https://metacpan.org/pod/Mac::FSEvents) and [Linux::INotify2](https://metacpan.org/pod/Linux::INotify2)) provide a filehandle
that you can use and IO event to watch.

This is not slight against the authors of those modules. Both are well 
respected, are certainly finer coders than I am, and built modules which 
are perfect for many situations. If one of their modules will work for you
by all means use it, but if you are already using an event loop, this
module may fit the bill.

lib/AnyEvent/Filesys/Notify.pm  view on Meta::CPAN

watcher to monitor the C<IO::KQueue> object.

B<WARNING> - L<IO::KQueue> and the C<kqueue()> system call require an open
filehandle for every directory and file that is being watched. This makes
it impossible to watch large directory structures (and inefficient to watch
moderately sized directories). The use of the KQueue backend is discouraged.

=head2 Fallback

A simple scan of the watched directories at regular intervals. Sets up an
C<AnyEvent-E<gt>timer> watcher which is executed every C<interval> seconds
(or fractions thereof). C<interval> can be specified in the constructor to
L<AnyEvent::Filesys::Notify> and defaults to 2.0 seconds.

This is a very inefficient implementation. Use one of the others if possible.

=head1 Why Another Module For File System Notifications

At the time of writing there were several very nice modules that accomplish
the task of watching files or directories and providing notifications about
changes. Two of which offer a unified interface that work on any system:
L<Filesys::Notify::Simple> and L<File::ChangeNotify>.

L<AnyEvent::Filesys::Notify> exists because I need a way to simply tie the
functionality those modules provide into an event framework. Neither of the
existing modules seem to work with well with an event loop.
L<Filesys::Notify::Simple> does not supply a non-blocking interface and
L<File::ChangeNotify> requires you to poll an method for new events. You could
fork off a process to run L<Filesys::Notify::Simple> and use an event handler
to watch for notices from that child, or setup a timer to check
L<File::ChangeNotify> at regular intervals, but both of those approaches seem
inefficient or overly complex. Particularly, since the underlying watcher
implementations (L<Mac::FSEvents> and L<Linux::INotify2>) provide a filehandle
that you can use and IO event to watch.

This is not slight against the authors of those modules. Both are well 
respected, are certainly finer coders than I am, and built modules which 
are perfect for many situations. If one of their modules will work for you
by all means use it, but if you are already using an event loop, this
module may fit the bill.

lib/AnyEvent/Filesys/Notify/Role/Fallback.pm  view on Meta::CPAN

use namespace::autoclean;
use AnyEvent;
use Carp;

our $VERSION = '1.23';

sub _init {
    my $self = shift;

    $self->_watcher(
        AnyEvent->timer(
            after    => $self->interval,
            interval => $self->interval,
            cb       => sub {
                $self->_process_events();
            } ) ) or croak "Error creating timer: $@";

    return 1;
}

1;

__END__

=pod

t/lib/TestSupport.pm  view on Meta::CPAN

}

sub received_events {
    my ( $sub, $desc, @expected ) = @_;

    $cv = AnyEvent->condvar;
    $cv->begin for @expected;

    $sub->();

    my $w = AnyEvent->timer(
        after => 3,
        cb    => sub { $cv->send } );

    $cv->recv;

    my @received_type = map { $_->type } @received;
    compare_ok( \@received_type, \@expected, $desc ) or do {
        diag sprintf "... expected: %s\n... received: %s\n",
          join( ',', @expected ), join( ',', @received_type );
        diag join "\n", @msgs;