> Squid knows if there is clients currently reading the (possibly old) > object, and it won't be deleted in such case until those clients are > done. Is that tracked by entry->mem_obj->clients?
I am still not comfortable with the structure that each URL maps to a StoreEntry and a MemObject while multiple store_client's share the same StoreEntry and MemObject. Is it possible that there's race condition? The code heavily relies on various flags of the StoreEntry and MemObject and things like inmem_hi/inmem_lo. Can you give me a crispy explanation why things won't get messed up (like race condition)? Thanks for you answer! -- Chengdu On Thu, 27 Mar 2003, Henrik Nordstrom wrote: > Chengdu Huang wrote: > > > This means every time we have a new swapoutable copy of a StoreEntry, > > it will be swapped out to a different swap file. > > Yes. > > > And I guess the old > > swap file of this StoreEntry will be removed by the disk space > > maintenance routine. Is that right? > > Actually a little before that. Squid deletes the file when the last > reference to the old object is gone. > > > I can imagine that this can avoid some race condition for simultaneous > > client requests, but wanna check with Squid vets here to make sure. > > Squid knows if there is clients currently reading the (possibly old) > object, and it won't be deleted in such case until those clients are > done. > > Regards > Henrik >
