Re: Implementing file-locking *control* in DBD::File

2009/12/4 H.Merijn Brand <[email protected]>:
> On Fri, 4 Dec 2009 10:03:54 +0100, Jens Rehsack
> <[email protected]> wrote:
>
>> 2009/12/3 H.Merijn Brand <[email protected]>:
>> > 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