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 _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
