Re: swap file number

> 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
>