Page 1 of 2
php executes multiple files simultaniously?
Posted: Tue Nov 30, 2004 12:36 pm
by josh
Not sure if this should go in php-code or not, decided to put it here because it's a question not directly related to code itself....
Does php execute multiple scripts at the same time? If so, what would happen if you had counter.php included on every file and counter.php incremented counter.txt or something, it takes a finite amount of time (as small as that amount of time may be) to open, write to, and close that file. So what if counter.php is called by 1,000 users a minute and if php parses multiple requests at the same time then it would be trying to write to the file twice at once... what would happen? Error? Would php take care of it for me? etc....
Thanks in advance
Posted: Tue Nov 30, 2004 1:12 pm
by Christopher
Yes, you're counter file would get very messed up because it would be written to or read by another process between your process's read and write. File locking is the solution.
Posted: Tue Nov 30, 2004 1:20 pm
by josh
So my script would do this:
if the file is locked wait a micro second and retry untill the file is not locked
lock the file to everyone except me
open the file write and close
unlock the file
Like that?
Posted: Tue Nov 30, 2004 2:32 pm
by Christopher
Yes. I posted a Perl::counter compatable counter class a while back (here
viewtopic.php?t=27982&start=17) but it does not have the locking part. It would need a loop around the open and the locking added to the read/write part. If you get a script working post it for others to see.
Posted: Tue Nov 30, 2004 3:31 pm
by djot
-
Anyway, filelocking does not work it seems, I always had reset counter-data-files after a while on several linux servers.
djot
-
Posted: Tue Nov 30, 2004 5:55 pm
by Christopher
Can others confirm that flock() does not really work?
Posted: Wed Dec 01, 2004 1:07 pm
by BDKR
Any reports of this behaviour in bugs.php.net?
Posted: Wed Dec 01, 2004 5:36 pm
by rehfeld
theres are bugs in certain versions of php for flock
but i think a lot of the "bugs" are people using flock incorrectly.
because it requires a file handle, many people create a race cond.
you could end up w/ stale data if you opened the file for read+write while another was writing to it, before you acheived the lock.
supposedly its due to prebuffering
i wonder why they didnt just make it so the lock was achieved BEFORE opening the file.....
i think the documentation for flock is poor, i should take a look at the source code.
Posted: Wed Dec 01, 2004 6:59 pm
by djot
-
rehfeld, was that an answer or a question, or just wondering?
What about your earlier contributions to php.net (if rehfeld.us is you?)?
http://www.php.net/manual/en/function.flock.php
djot
-
Posted: Wed Dec 01, 2004 8:00 pm
by rehfeld
i was just pondering why they made flock require a file pointer, instead of being able to lock a file before opening it.
yes that is my contrib on php.net, unfortunately, it has a bug/error
in the function i specified the default timelimit as 300000 seconds

i was thinking in microseconds, but my logic was flawed lol
i never noticed my mistake untill recently when i tried manually adding a lockdir, and set the perms on it so that php couldnt delete it.
i then found out the while loop was going to last a lonnnng time....
ive since fixed it, as well as made some minor changes, and asked for feedback on it here
viewtopic.php?t=28181
i wrote the function because i wanted a way to lock files that wouldnt fail due to a buggy version of php, because you cant always controll what version of php your host uses
Posted: Thu Dec 02, 2004 12:00 am
by BDKR
rehfeld wrote:i was just pondering why they made flock require a file pointer, instead of being able to lock a file before opening it.
Yeah, I agree. It's like saying, "Yeah, you can open that file, but we don't yet know if you should". The order of actions referred to need to be reversed.
That said, why not have a process do something like acquire a semaphore?
http://us2.php.net/manual/en/function.sem-acquire.php
Wouldn't this be a viable alternative, or is my logic flawed?
Cheers,
BDKR
Posted: Thu Dec 02, 2004 4:40 pm
by rehfeld
i guess the question would be, is acquiring a semaphore an atomic operation on all/most o/s?
i seems like it is, because thats kinda the purpose of it from what i understand
i found these
http://en.wikipedia.org/wiki/Dining_phi ... rs_problem
http://en.wikipedia.org/wiki/Sleeping_barber_problem
does anyone think maybe those problems are related to why flock requires a file handle?
im refering more to the possible deadlock situations they explain.
i started looking into it but this is getting kinda complicated for my little brain.
on a side note-today someone pointed out the error in my func on
http://php.net/flock lol
Posted: Thu Dec 02, 2004 6:57 pm
by BDKR
rehfeld wrote:
i guess the question would be, is acquiring a semaphore an atomic operation on all/most o/s?
Most likely, but even still, I get scared when we start talking about Windows.
rehfeld wrote:
i seems like it is, because thats kinda the purpose of it from what i understand
That's allways how I understood it and implemented it. Seems imperative for successfully implementing a system where multiple forked procs or threads are operating on a common hunk of memory or other resource.
rehfeld wrote:
i started looking into it but this is getting kinda complicated for my little brain.
Then relax.

There is a reason Joel wrote
http://www.joelonsoftware.com/articles/ ... rston.html.
Cheers,
BDKR
Posted: Fri Dec 03, 2004 12:44 am
by rehfeld
yeah, very well put

Posted: Sun Dec 05, 2004 7:23 pm
by josh
So I guess the answer to my questions is flock sucks, use a database?
Ok seriously.. could I create a tmp directory then just check if temp.dat exists,
if not create temp.dat then fopen fwrite fclose then unlink temp.dat
if it does exist wait for a few milliseconds and check again
because wouldnt file_exists('temp.dat') return true even if temp.dat was still being created... yes/no?