•Re: Effective use of IPC::Semaphore to limit number of concurrent executions of a scxipt

The problem with using a semaphore is that the kernel isn't smart enough to decrement the counter on your behalf if a process happens to abort early.

A better solution might be to implement an extended "highlander"-style solution as presented in my column that flocks one of N files instead of just one file. Then, if the process aborts for any reason, the flock is dropped, and a new process can claim its rightful slotishness.

I've had that extension to the highlander solution on my column to-do list for a number of months; perhaps it is time to finally write it up.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Comment on •Re: Effective use of IPC::Semaphore to limit number of concurrent executions of a scxipt

Replies are listed 'Best First'.
Re: •Re: Effective use of IPC::Semaphore to limit number of concurrent executions of a scxipt by ptkdb (Monk) on Oct 16, 2003 at 01:46 UTC
I beg to differ on what happens when the process aborts. If you have the SEM_UNDO flag set on your operations, all of the collective operations on that semaphore are 'undone'. I refer to the semop man page, and will see what my other reference material says about it in the morning.	[reply]