2009/12/4 H.Merijn Brand <h.m.br...@xs4all.nl>:
> On Fri, 4 Dec 2009 10:03:54 +0100, Jens Rehsack
> <rehs...@googlemail.com> wrote:
>
>> 2009/12/3 H.Merijn Brand <h.m.br...@xs4all.nl>:
>> > Any objections to me committing below change?
>>
>> While the originator of this request updates his ticket, maybe a smarter
>> implementation is reasonable:
>>
>> I could modify S::S opentable () to request opening for reading/writing,
>> so you could differ between LOCK_SH and LOCK_EX automatically.
>
> That can still be done. You can set a localized $data->{Database}{f_lock}
> What I have now done (and committed) is create support and
> documentation for locking control. How this will be used is up to the
> higher levels.
I wouldn't use the numbers 0..2 - I'd suggest using LOCK_SH, LOCK_EX
etc. instead.
This will help if any (exotic) OS defines it in the upper half byte or so.
>> Further, it could be suitable to or LOCK_NB, which allows to avoid deadlocks.
>
> LOCK_NB?
NON_BLOCK:
#define LOCK_NB 0x04 /* do not block when locking */
[...]
ERRORS
The flock() system call fails if:
[EWOULDBLOCK] The file is locked and the LOCK_NB option was specified.
> Apply or remove an advisory lock on the open file specified by fd. The
> argument operation is one of the following:
>
> LOCK_SH Place a shared lock. More than one process may hold a
> shared lock for a given file at a given time.
>
> LOCK_EX Place an exclusive lock. Only one process may hold an
> exclusive lock for a given file at a given time.
>
> LOCK_UN Remove an existing lock held by this process.
Might be unsupported on some OS. At least *BSD supports in (what
counts to me ^^).
>> Sorry for generating extra wishes ;)
>
> No need to be sorry. Wishes keep us sharp!
Than I wish a pony ;)
/Jens
