File-Information
view release on metacpan or search on metacpan
lib/File/Information/Tagpool.pm view on Meta::CPAN
return if $self->{_loaded_tagpool_pool};
$self->{_loaded_tagpool_pool} = 1;
$pv->{current} //= {};
$pv->{current}{tagpool_pool_path} = {raw => $self->{path}};
return unless $HAVE_FILE_VALUEFILE;
eval {
my $path = $self->_catfile('config');
my $reader = File::ValueFile::Simple::Reader->new($path, supported_formats => undef, supported_features => []);
$config = $reader->read_as_hash;
};
return unless defined $config;
$pv->{current}{tagpool_pool_uuid} = {raw => $config->{'pool-uuid'}} if defined($config->{'pool-uuid'}) && length($config->{'pool-uuid'}) == 36;
}
1;
__END__
=pod
=encoding UTF-8
=head1 NAME
File::Information::Tagpool - generic module for extracting information from filesystems
=head1 VERSION
version v0.17
=head1 SYNOPSIS
use File::Information;
my @tagpool = $instance->tagpool;
my @tagpool = $inode->tagpool;
my File::Information::Tagpool $tagpool = ...;
This module represents an instance of a tagpool.
B<Note:> This package inherits from L<File::Information::Base>.
=head1 METHODS
=head2 lock
my File::Information::Lock $lock = $pool->lock;
Locks the pool and returns the lock.
Some operations require the pool to be in locked state. Specifically all write operations.
When the pool is locked no other process or instance can access it.
The lock stays valid as long as a reference to C<$lock> is kept alive. See L<File::Information::Lock> about locks.
It is possible to acquire multiple lock objects from the same instance (C<$pool>). In that case the pool stays locked
until all lock references are gone.
B<Note:>
Locking the pool may take time as we might wait on other locks.
It may also fail (C<die>ing if it does) if no lock can be acquired.
B<Note:>
If you perform multiple write operations it will generally improve performance significantly to keep it locked.
To do this acquire a lock before you start your operations and hold for as long as you keep working on the pool.
However you should not lock the pool while idle to allow other processes to interact with it as well.
How long is too long is hard to answer in a general manner.
B<See also>:
L</locked>
=head2 locked
$pool->locked(sub {
# your code ...
});
This call run the passed coderef with an active lock. It is similar to:
{
my File::Information::Lock $lock = $pool->lock;
{
# your code ....
}
}
B<Note:>
It is safe to use this method even if you already hold a lock. This allows code calling this method
to not need to take notice about the current state of locking.
B<See also:>
L</lock>
=head2 load_sysfile_cache
my File::Information::Lock $lock ...;
$pool->load_sysfile_cache;
This method loads the pool's sysfile cache into memory. It will do nothing if the cache is already loaded.
The sysfile cache is only valid as long as the pool is locked. It is automatically discarded on unlock.
This method will also seed the instance's sysfile cache (see L<File::Information>).
The instance's cache may survive pool unlock.
B<Note:>
This method is normally not needed to be called manually. However if you perform a lot of read operations on the pool
(such as calling L<File::Information/for_link> or L<File::Information/for_handle> on a large number of different files)
this can be beneficial. It also allows to seed the cache ahead of time to speed up lookups later on.
B<Note:>
This method caches information on all sysfiles in the pool in memory. This can be memory expensive.
One should expect at least 1024 Byte of memory usage per file in the pool. For small pools this is of no concern.
However for larger pools it must be considered. Also, as this seeds the instance's cache not all of it may be gone
once the pool is unlocked. See L<File::Information> for it's cache handling.
( run in 3.200 seconds using v1.01-cache-2.11-cpan-14f38c9f855 )