Bruce Momjian wrote:
> > Göran Thyni wrote:
> >
> > Ouch, hate to say this but:
> > I played around with this last night and
> > I can't get either of the above technics to work with Linux 2.0.33
> >
> > I will try it with the upcoming 2.2,
> > but for now, we can't loose shmem without loosing
> > a large part of the users (including some developers).
> >
> > <PSEUDO CODE>
> > #ifdef HAS_WORKING_MMAP
> > flags = MAP_SHARED;
> > #ifdef HAS_MMAP_ANON
> > fd = -1;
> > flags |= MAP_ANON;
> > #else
> > fd = open('/dev/zero, O_RDWR);
> > #endif
> > area = mmap(0, size, PROT_READ|PROT_WRITE, flags, fd, 0);
> > #else
> > id = shget(...);
> > area = shmat(...);
> > #endif
> > </PSEUDO CODE>
> >
>
> What exactly did not work?
OK, here's the story:
Linux can only MAP_SHARED if the file is a *real* file,
devices or trick like MAP_ANON does only work with MAP_PRIVATE.
2.1.101 does not work either which means 2.2 will probably not
implement this feature (feature freeze i in effect for 2.2).
*But*,
(I was thinking about this,)
we should IMHO take a step backwards to get a better view
over the whole memory subsystem.
- Why and for what is shared memory used in the first place?
- Could we use mmap:ing of files at a higher level then
src/backend/strorage/ipc/ipc.c to get even better performance
and cleaness?
I will, time permitting, look into cleaning up the shmem-init/exit
routines
to work in a "no-exec" environment. I also has a hack to use
mmap-shared/private,
which of course is untested, since it does not work on my linux-boxen.
regards,
--
---------------------------------------------
Göran Thyni, sysadm, JMS Bildbasen, Kiruna