httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: Scoreboard redesign
Date Tue, 15 May 2001 20:54:19 GMT


> Bill Stoddard wrote:
> >
> > > 2. Add in code to update the data structure linkages (next pointers).
> > >    This would still use the existing algorithms for using indexes into
> > >    the allocated array and would still expect contiguous space. But
the
> > >    beginnings of the linked lists would be established.
> > > 3. Finish changing the code to remove any contiguous space
requirements.
> > >    All linked list work and use of worker_score pointers would be
> > >    implemented here. This is the first big step.
> >
> > This is not going to accomplish what we want (at least I don;t see it).
If
> > the parent allocates shared storage after the children have been forked,
the
> > pointers to this shared storage area are not necessarily the same across
the
> > child processes.  In other words, if the parent allocates shared
storage,
> > the pointer to that storage will not be the same value across the child
> > processes. Dean pointed this out on the apr-dev list.
> >
> > Bill
>
> For the time being, the shared storage will still be allocated in a "big
> chunk" up front (until we can figure out how to allocate and free smaller
> chunks). We will unfortunately still be allocating more than is usually
> needed, but will now be able to avoid allocating the (bigger) part related
> to mod_status if it isn't loaded. So overall it should usually be a
> memory savings.
>
> This "big chunk" can be viewed any way we want. Currently it is viewed
> solely as a fixed contiguous array using a formula to distinguish
> "process" records from "worker" records.
>
> The new design looks at the "big chunk" as a collection of "parts". Those
> "parts" are random and can be addressed via pointers and linked lists.
> The "parts" can be put back on the free list and reused. The workers
> for a given process do not need to be contiguous within the "big chunk",
> but the "big chunk" is still one big shared memory allocation.
>
> Does this make sense? Did I understand the question?

Yep, you understand my comment. You convinced me that there is value in
splitting out the mod_status portion of the scoreboard and managing the
chunks with lists (rather than arrays).

Bill


Mime
View raw message