That's a bad order to do things, is that how it worked?
There is a huge window while emitting the .gif during which other visitors may appear. At best a new visitor appearing during another visitor's "emit gif" phase does not increment the counter, at worst a visitor on a very slow line causes the cgi instance for this visitor to run for a long time and then write back a very old value to the file, making the counter run backwards.
For things that matter, the counter reading+increasing should be an atomic read-modify-write. But since this is just a web counter, I guess it's sufficient if you at least keep the hazardous window very small (by not doing the write-back at the end).
There is a huge window while emitting the .gif during which other visitors may appear. At best a new visitor appearing during another visitor's "emit gif" phase does not increment the counter, at worst a visitor on a very slow line causes the cgi instance for this visitor to run for a long time and then write back a very old value to the file, making the counter run backwards.
For things that matter, the counter reading+increasing should be an atomic read-modify-write. But since this is just a web counter, I guess it's sufficient if you at least keep the hazardous window very small (by not doing the write-back at the end).