Note that all PID-related methods are invoked before mainInitialize():
creating PID file ASAP was our goal here. Also, PID file operation
is a separate activity which has nothing common with DiskIO. In other
words, since DiskIO code knows nothing about PID file, it can't do any
harm with it.
I think your suggestion may be valuable but only after somebody
starts using File class in a threaded environment.
Eduard.
On 16.05.2017 15:21, Amos Jeffries wrote:
On 16/05/17 01:42, Eduard Bagdasaryan wrote:
Could you clarify, what are these processes that 'operate as
threads'? AFAIK,
Squid spawns its children by fork() and execlp(), and each new
process is a
common process with its own address space. As for atomicity, the OS
itself
guarantees that only one process can have an exclusive file lock at a
given time. Where do you suggest to use std::atomic then?
The main Squid binary is threaded via the DiskIO implementations (at
the least). These threads may be operational at any time after the
first StoreInit() call, and unfortunately do reach other parts of the
startup logic.
An static std::atomic lock/flag around the File::File() try{...}
internals to make it threadsafe should resolve any potential issues
there, the fnctl locks should be able to cope with anything once the
lock() method returns.
Amos
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
