Re: ideas

On Tue, Jun 13, 2000, Henrik Nordstrom wrote:

> > I still like the idea of a monolithic process for various reasons, but
> > I can be swayed with pseudo-code. I will attempt to throw together
> > some pseudo-code describing my idea tomorrow. Henrik and anyone else,
> > please do the same. I think this will help us all in sorting out a final
> > design that we can start coding on.
>
> The request forwarding is mostly a monolithic process, except that there
> might be more than one such process. The main coding difference from
> today is that the object store is separated from the networking, and
> that the request forwarding is centered around request forwarding, and
> not a StoreEntry.

Ok. As I said before, lets go with seperate processes using SYSVSHM to
communicate. I've been thinking about it a bit and if we do this right,
porting it to a threaded setup later shouldn't be that difficult, as
you pointed out.

If you have one network IO process per CPU to get SMP performance,
you still need :

* a common HTTP server socket
  - This isn't too hard, you just fork() off children with the FD, a la
    apache

* a common way of accessing statistics
  - This is going to be a little tricky to do efficiently - I thought about
    each process maintaining its own statistics and then the statistics
    are 'merged' whenever a request is made for them, but I'm not entirely
    sure about the mechanism to do this. If we put the stats inside a SHM
    segment, don't we have to wrap access with semaphores? I'm not entirely
    sure whether var++; is atomic enough here to not need a semaphore so
    someone clueful please give me some guidance here.

* a way of talking to the storage manager and handling hits
  - If the storage manager is implemented as seperate processes then some
    efficient method of talking between the storage managers and the
    network IO managers needs to be thought up.

Inside the network manager, are we going to go with a modular format like
what I proposed or something different?

Adrian

-- 
Adrian Chadd			Build a man a fire, and he's warm for the
<adrian@creative.net.au>	rest of the evening. Set a man on fire and
				he's warm for the rest of his life.