httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: [PATCH] Shared Memory Pools ;-)
Date Tue, 26 Jan 1999 10:42:26 GMT

In article <36ACCC29.62058608@icon-stl.net> you wrote:

> I saw no (obvious) way for a module to attach to a shared pool without knowing
> it's shared memory pointer address.  

Yes, there is no common denominator in shared memory approaches to make this
possible AFAIK. That's why I choose the approach to create a large shared
memory segment once before the childs are created and use an own memory
allocation library which works _completely inside_ this area.  

BTW, the same applies to the fact that AFAIK there is no way to enlarge a
shared memory segment in sync for parent and child processes. Actually with
some approaches like shmget/shmat you have no change to change the size at all
AFAIK.  And even with the mmap() approaches doing subsequent mmap()s in one
process will not change the mapping for other processes. On BSD systems
according to "The Design and Implementation of the 4.4BSD Operating System" it
would be possible because there the mapped regions are controlled by a shared
list when I understand it correctly, but that's far away from portable.
That's why my approach allocates a _large_ shared memory area at startup,
because it cannot allocate more on-demand. 

In practice this isn't a drawback, IMHO. Because shared memory pools should be
used just for explicitly needed to be shared data and those data is usually
just a few KBs per module. And the underlaying shared memory segment can be up
to 1MB in size on mostly all current Unix platforms (Solaris for instance
restricts a shmget() acquired area to around 1MB, FreeBSD allows more).

> That is, there's no identifying
> information for a pool other than its address.  

Yes.

> How would two modules sharing
> a pool communicate the pool's address between them?

That's a message passing idea between two modules. That's not the goal of my
approach. My approach for shared pools is to overcome the per-process address
space border and not the per-module communication border. My shared memory
pools solve the problem that a module wants to deal with own information which
should be shared across all httpd instances.

> I'm thinking

>   pool *p = create_or_use_a_shared_pool("Tool",sizeof(SharedRec));

> in order to either create a pool, or use it.

That's not possible AFAIK because when this is done in a child processes there
is no technical common denominator to sync the other childs with the created
pool. For some approaches like shmget/shmat or the non-anonymous mmap()
approach this would be possible. But for others it's not. And one of my goals
was to provide this functionality for _most_ of our platforms and such
features would reduce the platform list dramatically.

> I suppose the answer to my first statement is, that a module during its
> non-child initialization phase allocates the pool and all of its children end
> up with a copy of that pool pointer. 

Correct. That's what my mod_test I posted does.  But usually the pointer is
then stored in a module configuration structure and not in a global variable,
of course.

> But I'm not sure how to do the
> second....

AFAIK the second thing isn't technically possible when you want to support
mostly all Unix platforms which support shared memory.

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message