httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <rede...@raleigh.ibm.com>
Subject Re: Scoreboard redesign
Date Tue, 15 May 2001 15:14:29 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?

-- 
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein


Mime
View raw message