Prev: unicode
Next: subroutine
From: xhoster on 13 Jul 2006 12:58
from perldoc -f flock:

Note also that some versions of "flock" cannot lock things
over the network; you would need to use the more
system-specific "fcntl" for that. If you like you can force
Perl to ignore your system's flock(2) function, and so
provide its own fcntl(2)-based emulation, by passing the
switch "-Ud_flock" to the Configure program when you
configure perl.

Is there an easy way (a pragma or switch or something) to obtain the fcntl
based emulation *without* needing to recompile perl? Also, since flock
seems to be Perl's first choice over fcntl, I wonder why that is. What
disadvantages does building Perl with -Ud_flock have, other than this one:

Note that the fcntl(2) emulation of flock(3) requires that
FILEHANDLE be open with read intent to use LOCK_SH and
requires that it be open with write intent to use LOCK_EX.

Thanks,

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
From: Ben Morrow on 13 Jul 2006 13:26

Quoth xhoster(a)gmail.com:
> from perldoc -f flock:
>
> Note also that some versions of "flock" cannot lock things
> over the network; you would need to use the more
> system-specific "fcntl" for that. If you like you can force
> Perl to ignore your system's flock(2) function, and so
> provide its own fcntl(2)-based emulation, by passing the
> switch "-Ud_flock" to the Configure program when you
> configure perl.
>
> Is there an easy way (a pragma or switch or something) to obtain the fcntl
> based emulation *without* needing to recompile perl?

Not that I know of, but it would be trivial to write a replacement
yourself which calls fcntl.

> Also, since flock
> seems to be Perl's first choice over fcntl, I wonder why that is. What
> disadvantages does building Perl with -Ud_flock have, other than this one:
>
> Note that the fcntl(2) emulation of flock(3) requires that
> FILEHANDLE be open with read intent to use LOCK_SH and
> requires that it be open with write intent to use LOCK_EX.

fcntl locks

- can lead to unavoidable deadlocks (which the kernel ought to
detect for you).

- are often slower.

- aren't inherited across forks.

It's important to realize that the semantics are different:

flock $FH, LOCK_SH;
flock $FH, LOCK_EX;

will unlock the shared lock before applying the exclusive with flock(2),
but not with fcntl(2) emulation. This is the cause of the potential
deadlock, and the need to do deadlock detection is why locks can't be
inherited.

Ben

--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces mollit animos, tristesque mentes erigit.|benmorrow(a)tiscali.co.uk
Musica vel ipsas arbores et horridas movet feras. |
 | 
Pages: 1
Prev: unicode
Next: subroutine