Arranges for FILE to be read or written in ``binary'' mode on systems where the run-time libraries distinguish between binary and text files.
flock(FILE,OPERATION );
flock() is Perl's portable file locking interface, although it locks only entire files, not records.
OPERATION is one of LOCK_SH, LOCK_EX, or LOCK_UN, possibly combined with LOCK_NB. These constants are traditionally valued 1, 2, 8 and 4, but you can use the symbolic names if you import them from the Fcntl module, either individually, or as a group using the ':flock' tag. LOCK_SH requests a shared lock, LOCK_EX requests an exclusive lock, and LOCK_UN releases a previously requested lock. If LOCK_NB is bitwise-or'ed with LOCK_SH or LOCK_EX then flock will return immediately rather than blocking waiting for the lock (check the return status to see if you got it).
"after flock(file,2) other requests are ignored or are they 'logged'"
It depends -- after a sucessful flock(F,2) subsequent flock(F,2) calls on the same file will block (sleep) until the file becomes available. But flock(F, LOCK_EX & LOCK_NB) calls will return straightaway -- so you have to check the return code from flock() if you're doing that.
To be honest -- I'm not familiar with the Config module but yes -- I think it's safe to assume that $Config{'d_flock'} is imported from the Config module.
Mike
michael.j.lacey@ntlworld.com
Sorry, I didn't explain that very well, let me have another try.
A program that is used by more than one person at a time needs to coordinate its access to data files.
There are, basically, two approaches to this.
1 - The Blocking Approach.
(i) lock the file with [tt]flock(F, LOCK_EX)[/tt] waiting until it becomes available if it's already locked,
(ii) read/write the file as you need to (briefly -- other processes may be waiting for it)
(iii) unlock the file, any process that tried to lock it after (i) can now continue.
2 - The Non-Blocking Approach.
(i) try and lock the file with [tt]flock(F, LOCK_EX + LOCK_NB)[/tt]
if this does *not* succeed either fail the operation and tell the user to try again later or sleep() for a second or two then try again
if this *does* succeed..
(ii) read/write the file as you need to (briefly -- other processes may be waiting for it)
(iii) unlock the file
Approach 1 is simplest and usually sufficient for smallish applications. Its disadvantage is that a process might wait indefinitely for something that will never be unlocked by some other process that has becom locked.
Approach 2 is flexible enough to cope with files that might be locked for a long time but it is difficult (complex) to do properly.
Not a particularly easy topic, I hope that is clearer. Please ask again if there is something you don't understand.
Mike, you're help is extremely appreciated and you really shouldn't apologize.
What I'm trying to do is make a chatbox in Flash and to make it fast the text file is read every 5 seconds or so.
Now if a lot of people are chatting I think this whole flocking thing becomes a serious issue.
While reading the file I think it is better not use flock.
But while writing another message to the file I would like to avoid that the user only has to submit one time so if the file is locked it should wait till it is unlocked and write to it without alerting the user that submission failed.
will approach 1 be sufficient and how does all of this look like in code. Do I only have to write:
Approach 1 will probably be sufficient. And your code's right except that I think you have to call [tt]flock(F, LOCK_UN)[/tt] *before* closing the file. (nothing to [tt]flock()[/tt] otherwise)
"if a lot of people are chatting I think this whole flocking thing becomes a serious issue"
yep <smile>
Are you *sure* you don't want to flock the file while reading it? You won't be able to guarantee the user will see good data if you don't.... As long as the file is not large it will not be locked long for a read.
Talking of file size.... That text file might get quite long you know. Do you have a plan for handling that?
Mike
michael.j.lacey@ntlworld.com
if the file isn't flocked while reading than it means that it still can be written to. If at the same time a new message is written, it will be added at the bottom of the file. So I can't see how the user can get wrong data. Or am I wrong here? My thoughts are if the file is read every 5 seconds and a lot of people are chatting than writting to it might become a problem when the file is flocked each time while it is read.
About file size;
This chat box is part of a Flash game and actually what you brought up is another issue I thought of but didn't work out yet.
1. maximum number of messages will be around 50. While saving a new message the script should delete the top message when the number of 50 messages has been reached. I think I will be able to work this out.
2. (more difficult to find a smooth solution for). When nobody is online I would like the datafile to be 'erased' so there are no messages when the first user enters the chat box.
besides name and message, a third variable could be added for the number of users. When zero it will clear up the chat box. But I don't know how to deal with users that stopped the game without using the quit button. Another option is using a time buffer but this isn't perfect neither as the same users could still be online after the time buffer without having chat during this period.
Are there any 'standard' solutions known for this issue?
you can use the symbolic names if you import them from the Fcntl module, otherwise the numbers are fine
I think the standard solution is what you call the time buffer -- I would just make it good and long, an hour should do it.
- flocking while reading
I was thinking that it might be possible for a "reader" process to get a partially written file if it does a read halfway through a write by a "writer" process.
Mike
michael.j.lacey@ntlworld.com
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.