Re: Race condition in storeClose()

On Tue, Nov 28, 2000, Adrian Chadd wrote:

> > To me it seems that there are zillions of places in client_side.c
> > where client socket buffer is released without making sure that pending
> > aioread is canceled. Basically every place where we release client buff,
> > we should first cancel pending read with storeunregister, or have
> > clientbuffer cblocked, so that its final free is done during aiocallback
> > checks.
> > This part of squid is so complex that I'm very unsure about where and
> > what should we do with that.

.. and yes, what *should* happen here is that the store manager
gets a copy request, it gives the page to the store client on
the direct assumption that the store client doesn't modify that
page.

I couldn't find anywhere in client_side.c that actually *did* modify
the data page.

Personally, its overly complex because of the VM and non-VM functionality
people wanted. Part of what I wanted to do with the storage manager is
to rip out the memory cache altogether and push memory caching into
per-FS rather than in the storage manager. We have the added advantages
now over the squid-1 VM codebase that the storage manager can have quite
arbitrary filesystems hanging off it (one FS could be for transient
objects, or each FS that could handle a max_objectsize of -1 would
delay writing to the backing store and instead cache enough of the object
in memory to know whether it was transient or not..)

(One of the things that this would buy us when combined with the
storetree approach of each FS open/close/unlink/lookup on URI rather
than on swap_filen/swap_dirn is that it makes an SMP-friendly version
of squid a LOT easier to implement, and it could be done without
much(1) locking..)

I want to have something like this implemented for squid-2.6, as
squid-2.5 will be squid-2.4 with stable fixes and extra/faster
features, rather than rewritten subsystems like I want. :-)

Adrian

(1) - if you took reiserfs_raw as an example, you COULD have two squid
      processes running and BOTH accessing the same object store ..
      you could do some funny socket/tcp tricks at the upper levels and
      utilise a fine-grained-locking FS to get concurrancy without ever
      putting a mutex inside squid itself.

-- 
Adrian Chadd			"God: Damn! I left pot everywhere!
<adrian@creative.net.au>	  Now I'll have to create Republicans!"
				    - Bill Hicks