Re: Patch to retrieve send rights for shared memory objects

[Marcus Brinkmann]

At Tue,  1 Mar 2005 13:11:03 -0800 (PST),
Roland McGrath wrote:
> 
> >IMMAP0       IMMAP1  Meaning
> > 0   0       Not supported.
> > 1   0       Exactly no user.
> > 0   1       Maybe only one user (or more).
> > 1   1       Definitely more than one user.

It turns out that we can not actually determine the == 1 in any way,
not even approximately.  This is because GNU Mach keeps its own (and
seemingly only one) send right for a memory object in use.

This means that the number of send rights will usually be only 1
always, irregardless how many mappers there are, because the default
implementation of mmap() will release the shared memory object handle
after installing the mapping.  If however we keep an extra reference
around explicitely in the shared memory code, the number of extant
send rights will be "number of mapping tasks + 1 (for GNU Mach)".

It's a bit of black humour: we have the situation where either the
number is usually always 0 or 1, or where the number is usually 0 or 2+.

So, I want to back off a bit.  I have reviewed the source of several
important packages once more, and it seems that we will do OK with
just supporting the check for nattch == 0 or != 0.  I said earlier
that a check == 1 is important, but I am reconsidering:

firebird2 (a database) uses a check nattch == 1, but only if mmap() is
not available.  If mmap is available it doesn't seem to use SysV shm
at all.

libasound2 uses nattch == 1, but we don't have any sound architecture,
and definitely not ALSA.  Now, ok, that is a weak argument, but if
that's the only exception, I am happy to receive the bullet.

A lot of important other packages - from mozilla to xfree86, from
kerberos to gimp, don't need nattch at all.  postgresql checks for
nattch == 0, but the others don't check it at all.

So, I think I will work out a patch that only uses a single bit,
S_IMMAP0.  That's even (somewhat) reliable.  It doesn't give you the
number of mappings, but something that comes pretty close.  As we can
keep track of this flag all the time, we don't even need to call into
Mach to find out anything for io_stat().

Thanks,
Marcus