Re: ideas

Adrian Chadd wrote:

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

Yep. This would be the master process, monitoring and restarting
components as necessary.

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

SHM is needed I think, but each should write to it's own memory area to
avoid the locking/atimicy issues. Multiple readers/single writer are OK
without locking for statistical data, even when the writer difers for
different areas. It is not critical is a statistical reading are
slightly inconsistent.

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

Yep. Probably some kind of larger message based protocol with the bulk
data passed as shared memory (or mmap segments). Similar to the diskd
implementation, but operating at a higher level.

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

Something like what you proposed would be nice I guess. Only requirement
is that there must be a data tap somewhere where data is sent to the
store.

/Henrik
Received on Fri Jun 16 2000 - 15:45:41 MDT