Surely it doesn't matter how many instances are running, as long as you get your file locking right.

Update: There doesn't seem to be a module called "LickFile::Simple". But there really should be :-)

I always get the feeling that there are always problems involved with lockfiles. I can think of a 'permission denied' when creating one. I can think of a situation that the instance died unexpectedly. And what if different users run the same program, can they remove eachother lockfiles if necessary ?
I cannot imagine that all those examples are just nonsense, or is it ?

Anyway, it would be very nice to have this locking mechanism based on PIDs and the COMMANDs that were used!

LuCa

I'm not talking about lockfiles. I'm talking about using the file locking mechanisms that are built into your operating system. If you get an exclusive lock on a file, then any other process trying to get an exclusive lock on the same file will block until the first lock is released.

--


<http://dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club." -- Chip Salzenberg

jeanluca,

davorg has the right solution. You can have lots of instances of a program that reads a file or filehandle, but they will fail to read as soon as one instance starts up to lock and write that same filehandle. You need to accomodate that fail-to-read condition as well as fail-to-lock. It's really simple. Stevens is a good reference, everybody should (and most sysprogs do) own this.

Reading the /proc filesystem (through ps) to read PIDs & arguments is the way to do what you're trying to do, at least on Linux. You can then parse the response. It's not the way to solve your original problem, though.

Your use of '-w' for your write flag has bart scratching his head. He thinks you're referring to Perl's -w warnings-on switch. /me injects coffee into bart. :)

HTH. :D

Don Wilde
"There's more than one level to any answer."

Alternatively, Proc::ProcessTable::Process can retrieve the full command line of all the processes.