Amos Jeffries wrote: > Please use std::atomic > locks to ensure actually atomic operations on the file locks.
std::atomic<> is defined for integers and pointers. It is not defined for "file locks", which are complex OS-maintained objects largely invisible to Squid. C++11 std::atomic cannot magically make complex code thread-safe (and still working as intended). > 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. Protecting File::File() try {...} with a mutex does not make File objects thread-safe. > 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. By default, Squid code is not thread-safe and should not be thread-safe because thread safety costs a lot (and Squid threads are isolated, confined to a tiny subset of Squid code). Squid PID file management code is not thread-safe. Squid parts those threads "reach" have to be thread-safe, but they are not reaching the proposed code or the code it replaces. Please withdraw your request. Thank you, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev