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);

    [download]

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

    Cheers,
    KM

[reply]
[d/l]
      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!!!

      [download]
      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.
[reply]
[d/l]
        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

[reply]

In Section Code Catacombs