Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: Problem with flock?
Message-ID: <11014@jpl-devvax.JPL.NASA.GOV>
Date: 11 Jan 91 19:26:20 GMT
References: <1991Jan11.103201.26506@ircam.fr>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 19

In article <1991Jan11.103201.26506@ircam.fr> fingerhu@ircam.fr (Michel Fingerhut) writes:
: When flock is called on an already locked file descriptor with operation
: $LOCK_EX | $LOCK_NB (i.e., exclusive lock no block) it returns 0, which is
: contrary to the flock(2) description:
: 
: 	Requesting a lock on an object that is already locked normally
: 	causes the caller to blocked until the lock can be acquired.  If
: 	LOCK_NB is included in operation, the call is not blocked;
: 	instead, the call fails and the error EWOULDBLOCK is returned.
: 
: This works correctly in C programs.
: 
: Any help/suggestions?

As with most Perl functions, Perl returns true for success and false for
failure.  It's a bug that this isn't documented under flock in the man page
for Perl.

Larry