File-Information
view release on metacpan or search on metacpan
lib/File/Information/Lock.pm view on Meta::CPAN
=head1 METHODS
=head2 new
my File::Information::Lock $lock = File::Information::Lock->new([ instance => $instance, ] parent => $parent, on_unlock => \&unlock_sub);
Returns a new lock object. Requires an instance (L<File::Information>), a parent object (what is locked), and an unlock function.
If no instance is given C<$parent-E<gt>instance> is called to obtain one.
Once this lock is gone the unlock function is called. It is normally a private method of the object that is locked.
The unlock function is responsible of handling the case with multiple lock objects being alive at the same time. So any unlock function must check
if all locks are gone before performing an actual unlock. The unlock function is called on C<$parent> and passing the lock as first argument.
=head2 instance
my File::Information $instance = $lock->instance;
Returns the instance that was used to create this object.
=head2 parent
lib/File/Information/Tagpool.pm view on Meta::CPAN
=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.
( run in 1.095 second using v1.01-cache-2.11-cpan-14f38c9f855 )