apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: Shared memory and IPC
Date Fri, 07 Sep 2001 10:30:43 GMT
On Fri, Sep 07, 2001 at 05:17:01AM -0500, Peter Samuelson wrote:
> 
> [Wez Furlong]
> > So there is no nice-n-easy syscall then?  Even a non-portable call
> > would be better than parsing /proc/self/maps.
> 
> Don't look at me, I'm no IPC expert!  (So, that out of the way...)
> 
> I am not sure what you are wanting beyond mmap(MAP_FIXED).  That is
> indeed a nice-n-easy syscall -- it will either succeed or fail.  If it
> succeeds in one process but fails in another, just munmap() it again.
> 
> The real question is, what *do* you do on failure?  One possible
> protocol: the "master" process does mmap() without MAP_FIXED, reports
> the address to the others via some sort of existing IPC, the rest try
> with MAP_FIXED, report back success or failure.  If anyone fails, they
> all unmap *except* the master, which repeats the process with another
> mmap() [again without FIXED] ... for a specified number of tries.  Upon
> success, or upon giving up, the master munmaps all failed segments, if
> any.

see, this is the bit that i was hoping that noone would suggest
even be attempted, even though it's technically a correct
solution :)

now we have a good reason to justify why MS reserves 2gb of the
physical memory address space in w95...

the only issue with mmap() without MAP_FIXED is that you
won't get a real physical address back, you'll get a
virtual address back.

if this is the case, the algorithm is sound, but the "master"
would still need to use mmap(MAP_FIXED) with ever-increasing
addresses on segment boundaries, and it could also unmap them
on failure.

luke

Mime
View raw message