Thank you! I dropped the .lock file and am now locking the script itself. It appears I can lock it again, with no apparent side effect, if it was locked earlier. Found a neat way of referencing the running script without using DATA but now can't find the site to reference it.
The lock_retrieve and lock_nstore were intended to keep other processes waiting, whilst the updated data is being flushed to the cache file.
Herewith the resulting script snippet:
my $cache_ttl = 60; my $cachefile = '/tmp/mtapi.'.$router.'.cache'; my %bgp_peer; my $cached = 0; my $modified = (stat($cachefile))[9]; open our $lockfile, '<', $0 || die $!; if (defined $modified) { if (($modified >= (time-$cache_ttl)) || (!flock $lockfile, LOCK_EX | + LOCK_NB)) { if (%bgp_peer = %{lock_retrieve($cachefile)}) { $cached = 1 }; } } if ($cached == 0) { if (!flock $lockfile, LOCK_EX | LOCK_NB) { print STDERR "Another pro +cess is already using MikroTik API.\n"; exit 6 }; $api->connect(); $api->login(); %bgp_peer = $api->get_by_key('/routing/bgp/peer/print', 'name'); $api->logout(); lock_nstore \%bgp_peer, $cachefile; chmod 0660, $cachefile; flock $lockfile, LOCK_UN; }
In reply to Re^2: Faster locking
by bbs2web
in thread Faster locking
by bbs2web
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |