In article <[EMAIL PROTECTED]> you wrote:
>> > MM does not have a malloc-like API. It comes close, but the first thing
>> > MM makes you do to get shared memory, is to decide how much shared memory
>> > you want total. That would be fine, but then if I request 1024k of shared
>> > memory, and only allocate it in smaller blocks, then MM will use portions
>> > of my 1024k for itself. That means that I can't allocate all 1024k for
>> > myself.
>>
>> And what do you suggest for improvement, Ryan?
>>
>> The only really reasonable possibility from my point of view (and
>> which is in my TODO list for a longer time) is that MM's "Standard
>> Malloc-Style API" bases its memory pool not on just a single shared
>> memory segment, but on multiple segments and then automatically adds a
>> segment if the pool is exhausted. A patch for this is welcome.
>
> this doesn't even sound possible at all. you can't force a shared memory
> mapping to appear at the same address in another process, and you can't
> even force another process to attach a new shared mem segment.
>
> this would mean you couldn't use pointers in the shared memory. ok maybe
> this is already a restriction and you guys use offsets from the shm base.
> but with a dynamically expandable change like this then you're going to
> require every offset/pointer dereference is going to require a test first
> to see if that part of the shared memory is already mapped.
>
> not to mention that unless you've got sysv shm, then you need to create
> files on disk somewhere to be backing store for the memory, because
> there's no other way to pass a segment to another, already existing
> process.
No, Dean, I think you misunderstood me here. If the shared memory
segment is full, I don't want to _replace_ it with a larger one. I
just want to _add_ another _new_ shared memory segment to the memory
pool and allocate the requested chunk of memory from there instead. The
same way a heap-based allocator uses sbrk(2) again and again to get more
heap segments I want to allocate more and more shared memory segments.
> i really think that MM's rather simple API is the right API. and that
> what's being suggested is overkill, and will hurt performance.
What type of API do you suggest instead, Dean?
> it sounds to me like what the "must look like malloc" folks want is more
> commonly referred to as multithreaded programming.
<grin> Yes, maybe...
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
