----- Original Message -----
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 14, 2001 3:03 AM
Subject: Re: Status Shared Memory
> On Sat, Jul 14, 2001 at 09:40:59AM +0200, Rivium wrote:
> > But my Main Goal is to speed things -really- up. So i was talking about
> > segment of shared memory, on the same machine
> > (I love the current Memory prices!)
>
> Shared memory has major problems. Consider the fact that you can't
> store any pointers in shared memory nor can you expand the memory once
> you have allocated it (with most implementations AFAIK).
1. Yes, you can store offsets, rather than pointers. This makes it impossible
to store APR structures (e.g., an apr_table), but quite possible to store
your own data.
2. All clients need to re-map when the memory is expanded. The simplest
mechansim is a shmem section of memory, with a tag.
> The reason that you can't use pointers is that users of the shmem will *not*
> receive the memory at the same location in each process. So, about
> the only thing you can store is raw text or arrays of known size in
> shared memory (like the scoreboard which isn't that big and has known
> size at compile-time).
Very true. Stash the bounds, or size, inside the structure.
> IMHO, you're better off using true IPC mechanisms - especially when
> you are concerned about scalability (as you seem to be). Shared
> memory doesn't scale. If I'm wrong, please correct me. =) In
> your scenario, mmap() *may* provide a better alternative and remains
> file-based, and will be significantly faster than plain read()/write()
> (as long as you don't run out of address space). -- justin
MMAP shouldn't be significantly faster at run time, only during allocation.
Most systems have memory backed by a file, only it's a swap image, rather
than a shmem file.
