The RaQ line used Apache which definitely supported concurrent requests. We're talking about 1999 here. Maybe this isn't as obvious to people today looking back, but concurrent request handling was absolutely required from the beginning: consider how slow your clients are! One single client on a slow dial-up modem can't be allowed to drag the whole site down.
It will be a forking web server. But the CPU scheduler will schedule process A while B is opening the file and reading and that. While B is then increasing the counter, leading to multiple processes with "wrong" data.l racing for the writes.
As I remember it, you would flock the file. You didn’t care if another process blocked for the short period it was held. It is not like you were getting huge amounts of traffic.
Comments
This is likely what was done. Nobody really cares if a hit counter on a web page loses a few updates.
Given it's a single-threaded CPU, there's a fair chance the web server isn't concurrent anyway.
Linux got proper POSIX thread support with NPTL only in 2002.
The RaQ line used Apache which definitely supported concurrent requests. We're talking about 1999 here. Maybe this isn't as obvious to people today looking back, but concurrent request handling was absolutely required from the beginning: consider how slow your clients are! One single client on a slow dial-up modem can't be allowed to drag the whole site down.
It will be a forking web server. But the CPU scheduler will schedule process A while B is opening the file and reading and that. While B is then increasing the counter, leading to multiple processes with "wrong" data.l racing for the writes.
As I remember it, you would flock the file. You didn’t care if another process blocked for the short period it was held. It is not like you were getting huge amounts of traffic.