On Fri, 2003-03-07 at 13:51, R. Joseph Newton wrote:
> Wiggins d'Anconia wrote:
>
> >
> > In general this would be handled with a lock file. When the first
> > instance of your script starts it would check for the lock file if it
> > exists then just exit, if it doesn't then it opens a file (.lock for
> > example) then does its processing, and then removes the lock just before
> > exiting. If another instance of the script starts while the lock file
> > exists it will see it and close.
> >
> > For example:
> >
> > my $lockfile = '.lock';
> >
> > exit if (-e $lockfile);
> >
> > # try to get the pid file...."
> > open(LOCK, ">$lockfile") or die "unable to open lock file: $!";
> > print LOCK $$;
> > close(LOCK) or die "unable to close lock file: $!";
> >
> > # do processing here.....
> >
> > unlink $lockfile or die "unable to remove lock file: $!";
>
> Good idea, but I think the lock file in this case needs a little more
> information--specificically, the ip address currently being inserted into the
> blacklist file. That way, if the new ip in the queue is identical to the one being
> inserted, the insertion is dropped, but if the ip is different, it waits in the
> queue to be added next.
>
> Joseph
Probably worth using lock-file modules and/or programs already out
there, if you don't take care of every condition you can get into
trouble... the things that i can think of of the top of my head are:
(these conditions can happen in the above code)
* Stale lock file
* Race conditions, eg.
* 1st process comes and passes the -e $lockfile test
(aka no lockfile exists)
* 2nd process starts and checks for the $lockfile before
the first process has had a chance to:
open(LOCK, ">$lockfile")
I'd probably start looking at semaphores to solve some of the issues and
timed autounlocks for stale files etc...
As you can see though, if you want a fairly reliable locking system, you
do have to take care of quite a few conditions...
simran.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
