You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modules-dev@httpd.apache.org by Christiaan Lamprecht <ch...@googlemail.com> on 2006/11/22 21:12:17 UTC
Shared memory
I'm trying to share some WRITABLE memory between apache requests...
This means that I'll need to use APR mutex's and the like but can
anyone suggest where the best place is to store such writable data.
(short of having to write it to a file, I'm looking for something less
costly) Is the module's server/directory config space appropriate to
write to at runtime?
Many many thanks in advance for any help
Christiaan
Re: Shared memory
Posted by Sander Temme <sc...@apache.org>.
On Nov 24, 2006, at 7:58 AM, Christiaan Lamprecht wrote:
> typedef struct {
> char* variable1;
> char* variable2;
> } ASSLFilter;
>
> apr_shm_create(&assl_shm, sizeof(ASSLFilter) * 20, (const char *)
> shmfilename, pconf);
<..>
> Can I make use of shm to extend the memory for each char* in the
> struct? e.g. shm_attach
All you end up having shared are the pointers to your strings. Other
processes can't see that data those point to, because that lives
within the process environment of the process that made the initial
assignment.
You could make your shared memory segment large enough to hold the
entire strings (say, char[256] variable1;), but you'll need to be
careful to avoid buffer overflow issues especially if you fill that
variable with remote input.
Another approach would be to create a second (and third) shm segment,
and stash pointers to those in the first record. The child processes
would check those pointers for NULL, and if they exist, attach to the
shared segments and use them.
Of course this is kind of inefficient if the data for variable1 and
variable2 itself is variable in size... makes it almost interesting
to look at some database structure behind your module that abstracts
the issues associated with variable size data. Don't we have bdb
capability now inside the server?
S.
--
sctemme@apache.org http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Shared memory
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
Thanks for the help everyone!
Mutex's and shm seems to be working fine. I do however need to change
the shared memory at runtime! which is a problem as char* variable1 &
2 is assigned a value (by the client, so the size is unknown at
startup) when a client makes an http request...
typedef struct {
char* variable1;
char* variable2;
} ASSLFilter;
apr_shm_create(&assl_shm, sizeof(ASSLFilter) * 20, (const char *)
shmfilename, pconf);
I have tried allocating my own memory for the variables but it seems
to be overwritten (by something) when the next request gets the shared
shm.
Also tried using APR pools:
ASSLFilter *assl_filter_list = (ASSLFilter *)apr_shm_baseaddr_get(assl_shm);
assl_filter_list[i].variable1 = apr_pstrdup(r->server->process->pool,
variable1);
but once again it seems to have disappeared.
Can I make use of shm to extend the memory for each char* in the
struct? e.g. shm_attach
Thanks again
Christiaan
Re: Shared memory
Posted by Sander Temme <sc...@apache.org>.
Christiaan,
On Nov 22, 2006, at 12:12 PM, Christiaan Lamprecht wrote:
> I'm trying to share some WRITABLE memory between apache requests...
> This means that I'll need to use APR mutex's and the like but can
> anyone suggest where the best place is to store such writable data.
> (short of having to write it to a file, I'm looking for something less
> costly) Is the module's server/directory config space appropriate to
> write to at runtime?
You can use shared memory. Back in the dark days of Apache 1.3, you
had to use MM or do something platform-specific. Now, APR offers a
shared memory implementation that will make a read/write block
available to all httpd children.
You might take a look at http://www.temme.net/sander/
mod_example_ipc/ , a very bare bones example of a counter maintained
between httpd children and requests.
I'm using apr_global_mutex_t. If your httpd is not threaded, and APR
is compiled with --disable-threads, its behaviour reverts to
apr_proc_mutex_t.
S.
--
sctemme@apache.org http://www.temme.net/sander/
Open Source Software Consultant
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Shared memory
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Christiaan Lamprecht wrote:
> On 11/22/06, Brian McQueen <mc...@gmail.com> wrote:
>> In an old thread dated October 9, with the subject "server config
>> apr_table_t" there was some talk about this issue and it was mantioned
>> that the server config structure is to be considered non-volatile.
>> Did I get that right?
>
>>> On 10/10/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>>> All of them. Understand that all malloc()ed memory heap pages in most
>>> kernels are shared but marked copy-on-write. As soon as any forked
>>> process (every httpd child worker process) touches one byte in those
>>> pages, they get their own copy of the memory that's then modified.
>>>
>>> If you never write to pconf, then all child processes will continue to
>>> share the same, single copy. Until one writes to it, potentially
>>> chewing up alot of memory if there are many processes and many small
>>> changes in that pool. That's why I say touching the global pools
>>> such as pconf is just a bad idea.
>
> Currently I'm using the server config but allocating my own memory
> (i.e. non-APR) So this should work? Albeit potentially playing with
> fire.
That's bad (non-APR memory) only when it isn't cleaned up and your module
doesn't withstand long-term operation. The safest is to allocate a sub
pool from the request pool for per-request allocations, of a subpool from
the connection pool for socket-lifetime operations.
These are discarded (with your data) on recycle.
Re: Shared memory
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 22 Nov 2006 23:11:40 +0000
"Christiaan Lamprecht" <ch...@googlemail.com> wrote:
> >>If you never write to pconf, then all child processes will continue
> >>to share the same, single copy. Until one writes to it, potentially
> >>chewing up alot of memory if there are many processes and many small
> >>changes in that pool. That's why I say touching the global pools
> >>such as pconf is just a bad idea.
>
> Currently I'm using the server config but allocating my own memory
> (i.e. non-APR) So this should work? Albeit potentially playing with
> fire.
There's nothing wrong with allocating your own memory. But neither
is it necessary for any reason related to the passage you quote:
your module can create its own pool from pchild in a child_init
hook and use that.
In either case, it's up to you to manage it.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Shared memory
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
On 11/22/06, Brian McQueen <mc...@gmail.com> wrote:
> In an old thread dated October 9, with the subject "server config
> apr_table_t" there was some talk about this issue and it was mantioned
> that the server config structure is to be considered non-volatile.
> Did I get that right?
>>On 10/10/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>>All of them. Understand that all malloc()ed memory heap pages in most
>>kernels are shared but marked copy-on-write. As soon as any forked
>>process (every httpd child worker process) touches one byte in those
>>pages, they get their own copy of the memory that's then modified.
>>
>>If you never write to pconf, then all child processes will continue to
>>share the same, single copy. Until one writes to it, potentially
>>chewing up alot of memory if there are many processes and many small
>>changes in that pool. That's why I say touching the global pools
>>such as pconf is just a bad idea.
Currently I'm using the server config but allocating my own memory
(i.e. non-APR) So this should work? Albeit potentially playing with
fire.
Thanks
Christiaan
Apologies for re-posting the snippet, if that's against etiquette
Re: Shared memory
Posted by Brian McQueen <mc...@gmail.com>.
In an old thread dated October 9, with the subject "server config
apr_table_t" there was some talk about this issue and it was mantioned
that the server config structure is to be considered non-volatile.
Did I get that right?
On 11/22/06, Christiaan Lamprecht <ch...@googlemail.com> wrote:
> >On 11/22/06, Nick Kew <ni...@webthing.com> wrote:
> > IPC adds complexity, and is of course slower than working
> > within-process. You'll need an shm segment, or something more
> > persistent like a DBM.
>
> You mentioned using that using the server config for the shared
> resources is ok. I gather that shm/dbm are other ways of doing the
> same thing. (e.g. SSL uses it for caching) but I can get away with
> using the server config instead..?
>
> > I asked the publisher about that just a few days ago. Apparently
> > we're too near to release for them to think offering previews is
> > worthwhile. I'm contemplating doing something off my own bat:
> > maybe accepting orders myself, and sending relevant PDFs in advance,
> > then the book when it's available.
>
> Well, see what works, I'll be waiting...
>
>
> Thanks
> Christiaan
>
Re: Shared memory
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
>On 11/22/06, Nick Kew <ni...@webthing.com> wrote:
> IPC adds complexity, and is of course slower than working
> within-process. You'll need an shm segment, or something more
> persistent like a DBM.
You mentioned using that using the server config for the shared
resources is ok. I gather that shm/dbm are other ways of doing the
same thing. (e.g. SSL uses it for caching) but I can get away with
using the server config instead..?
> I asked the publisher about that just a few days ago. Apparently
> we're too near to release for them to think offering previews is
> worthwhile. I'm contemplating doing something off my own bat:
> maybe accepting orders myself, and sending relevant PDFs in advance,
> then the book when it's available.
Well, see what works, I'll be waiting...
Thanks
Christiaan
Re: Shared memory
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 22 Nov 2006 21:39:12 +0000
"Christiaan Lamprecht" <ch...@googlemail.com> wrote:
> >On 11/22/06, Nick Kew <ni...@webthing.com> wrote:
> > You can use the server config for that. You already know you need
> > the mutex; you'll also need to consider the lifetime of what's being
> > stored and avoid a memory (or similar resource) leak. If your
> > memory is shared by all processes, it gets more complex.
>
> More complex due to potential memory leaks, use of appropriate mutex's
> or something else?
IPC adds complexity, and is of course slower than working
within-process. You'll need an shm segment, or something more
persistent like a DBM.
> > My Chapter 4 has some examples covering a couple of scenarios.
>
> Anywhere I can look before the book is released?
I asked the publisher about that just a few days ago. Apparently
we're too near to release for them to think offering previews is
worthwhile. I'm contemplating doing something off my own bat:
maybe accepting orders myself, and sending relevant PDFs in advance,
then the book when it's available.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Shared memory
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
>On 11/22/06, Nick Kew <ni...@webthing.com> wrote:
> You can use the server config for that. You already know you need
> the mutex; you'll also need to consider the lifetime of what's being
> stored and avoid a memory (or similar resource) leak. If your memory
> is shared by all processes, it gets more complex.
More complex due to potential memory leaks, use of appropriate mutex's
or something else? (I have used apr_global_mutex instead of the 'proc'
or 'thread' versions to hopefully avoid any unforeseen problems) Any
clues of what to avoid/keywords to google?
> My Chapter 4 has some examples covering a couple of scenarios.
Anywhere I can look before the book is released?
Thanks again
Christiaan
Re: Shared memory
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 22 Nov 2006 20:12:17 +0000
"Christiaan Lamprecht" <ch...@googlemail.com> wrote:
> I'm trying to share some WRITABLE memory between apache requests...
Ambiguous requirement.
> This means that I'll need to use APR mutex's and the like but can
> anyone suggest where the best place is to store such writable data.
> (short of having to write it to a file, I'm looking for something less
> costly) Is the module's server/directory config space appropriate to
> write to at runtime?
You can use the server config for that. You already know you need
the mutex; you'll also need to consider the lifetime of what's being
stored and avoid a memory (or similar resource) leak. If your memory
is shared by all processes, it gets more complex.
My Chapter 4 has some examples covering a couple of scenarios.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Shared memory
Posted by Joachim Zobel <jz...@heute-morgen.de>.
Am Mittwoch, den 22.11.2006, 20:12 +0000 schrieb Christiaan Lamprecht:
> I'm trying to share some WRITABLE memory between apache requests...
> This means that I'll need to use APR mutex's and the like but can
> anyone suggest where the best place is to store such writable data.
> (short of having to write it to a file, I'm looking for something less
> costly) Is the module's server/directory config space appropriate to
> write to at runtime?
I would recommend a relational database. The problem with files is IMHO
not speed, its that you have to do explicit locking.
Sincerely,
Joachim