Re: squid rewrite

Andres Kroonmaa wrote:
> =

> As your thoughts are quite similar to those I have thought of for
> quite some time, I would like you to take a look at these ideas and
> comment aggressively. As it appeares to be too big to include with a
> mail, here is a URL: http://cache.online.ee/cache/Devel/design.txt

I'll do so.

> I think that squid sooner or later will need to have best of
> VM and NOVM versions mixed. NOVM has no problem with large
> objects, and if it uses VM style for objects near average
> size (10-20K) it can also conserve FD's and keep most hot
> objects in VM still being able to manage memory usage.

Have anyone made any reliable comparasion on how much performance is
gained by having a internal hot-objects cache as compared with file
system? (the objects should be in memory in both cases.. the filesystem
has it own set of cache pages).

But I agree that the 1.2 series should only need one.. it should not
have any of the basic problems that the current trees have (VM or FD
usage).

> Semaphores can be implemented in software in worst case, but
> is shared memory really a porting problem?

It depends on how you use it, which in turn depends on which design is
choosen for Squid. It might be possible to make a reliable
implementation, but it will require a great deal of research and testing
to figure out all the different issues on the different platforms.

It should be possible to use shared memory for "simple" IPC, but the
more complex operations, the more problems with locking and OS
dependencies. And for simple operations we are probably better off using
pipes (or some other stream oriented channel).

---
Henrik Nordstr=F6m