Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

RE: Re: This is weird...

by Kozz (Friar)
on Jun 17, 2000 at 18:14 UTC ( #18639=note: print w/ replies, xml ) Need Help??


in reply to Re: This is weird...
in thread This is weird...

chromatic:
Your explanation, which of course makes perfect sense, made me think more about the use of flock; You stated, "I wouldn't do it here, but that's just me." I have no doubt you have a reason for this, and I'd actually like some insight on your suggested uses of flock.

In addition, I imagine that the flocked file is automatically un-flocked when it is closed, but is there any benefit(s) to explicitly calling flock(TEST, 8) before closing the file?


Comment on RE: Re: This is weird...
RE: RE: Re: This is weird...
by turnstep (Parson) on Jun 17, 2000 at 19:10 UTC

    > In addition, I imagine that the flocked file is
    > automatically un-flocked when it is closed, but
    > is there any benefit(s) to explicitly calling
    > flock(TEST, 8) before closing the file?

    In general, no, there is no reason to call flock, especially if you are about to close the file. Perl will unlock the file for you. If you exit the script without closing the file, perl will unlock it and close it for you.

    I can think of only two times where one might want to explicitly unlock a file through flock:

    First, you may want to check the return code and see whether or not the unlock succeeded or failed. In reality, this is a very rare event. File locking, on the other hand, can fail for many reasons, and the value should always be checked. Once a file has been locked, in other words, it is very unlikely that an unlock will fail. I would only add this in after a problem had been found, as part of an advanced debugging process. Then again, checking the status doesn't really make your code any slower, so whatever you are comfortable with.

    The second reason to unlock a file is if there is going to be a long pause in which you are not going to use the file, but you do not want to close it yet. For example, take this script that adds a timestamp to a logfile at a random interval (perhaps it picks a random visitor to win something?)

    my $logfile = "/foo/bar.log"; my $loops=0; open(FOO, ">>$logfile") || die "Could not open $logfile: $!\n"; flock(FOO, 1) or die "Could not lock $logfile: $!\n"; print FOO "**Begin timestamping**\n"; { print FOO "**", scalar localtime, "**\n"; flock(FOO, 8) or die "Could not unlock $logfile: $!\n"; $loops>500 and last; sleep(60*(rand(6)+5)); flock(FOO, 1) or die "Could not lock $logfile: $!\n"; redo; } close(FOO); exit;

    Not a very useful script, but it illustrates the point. I'd probably open and close it every time.

RE: RE: Re: This is weird...
by chromatic (Archbishop) on Jun 17, 2000 at 21:05 UTC
    I would only use flock if I wanted to access a file and keep any other bits of my program from doing so at the same time. If I thought there were a possibility that one bit could start writing to it, another would become active and start writing to it, that could result in a corrupted output file.

    The problem is, flock tends to be advisory. If you really want to ignore a lock on a file, you can get around that.

    In a small program like this, I don't bother with file locking. In larger programs, where there's an issue of concurrency, it does come up. (So do a lot of other things.)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://18639]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (18)
As of 2014-07-10 19:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (215 votes), past polls