Open Stack

On 08/20/2014 01:40 AM, Angus Lees wrote:
> On Mon, 18 Aug 2014 10:05:28 PM Pádraig Brady wrote:
>> On 08/18/2014 03:38 PM, Julien Danjou wrote:
>>> On Thu, Aug 14 2014, Yuriy Taraday wrote:
>>>
>>> Hi Yuriy,
>>>
>>> […]
>>>
>>>> Looking forward to your opinions.
>>>
>>> This looks like a good summary of the situation.
>>>
>>> I've added a solution E based on pthread, but didn't get very far about
>>> it for now.
>>
>> In my experience I would just go with the fcntl locks.
>> They're auto unlocked and well supported, and importantly,
>> supported for distributed processes.
>>
>> I'm not sure how problematic the lock_path config is TBH.
>> That is adjusted automatically in certain cases where needed anyway.
>>
>> Pádraig.
> 
> I added a "C2" (fcntl locks on byte ranges) option to the etherpad that I 
> believe addresses all the issues raised.    I must be missing something 
> because it seems too obvious to have not been considered before :/
> 

I've added some additional comments to the etherpad, but the only
problem I'm aware of with using lock files was that it requires
lock_path to be set and have secure permissions.  Whether we lock entire
files or byte ranges, that is still true.  Also, we still need the
ability to use different lock files because some locks use a specific
file path that isn't in our configured lock_path, and this is necessary
behavior until we can replace it with tooz or something.

Also, I believe it has the same hash collision issue as sysv semaphores.
 While it's hugely unlikely that a hash would collide in the number of
bits we're dealing with, an unlucky collision would be a nightmare to
debug.  All things being equal I'd prefer to eliminate the chance entirely.

-Ben