On Mon, 2 Oct 2000, Austin Donnelly <[EMAIL PROTECTED]> wrote:
> On Monday, 2 Oct 2000, Raphael Quinet wrote:
> > FYI, I have added the following lines to /etc/system on all Solaris
> > machines that I use:
> > 
> > # increase shared memory limits (for GTK+ applications)
> > set shmsys:shminfo_shmmax = 0x2000000
> > set shmsys:shminfo_shmmni = 0x1000
> > set shmsys:shminfo_shmseg = 0x100
> > 
> > By default, Solaris has a limit of 6 shm segments per process, 100 in
> > total, and allows a maximum segment size of 1 MB.  You can check the
> > current values by running the command /usr/sbin/sysdef.  By increasing
> > all of these parameters, I am sure that I can use many GTK+
> > applications without warnings.
> Can whoever maintains the FAQ add a question on this to it, please?

The Gimp User and Developer FAQs are (were?) maintained by Miles
O'Neal who is (was?) on this list, but they have not been updated
since January 1999 and they still contain many obsolete entries
refering to versions 0.99.x of GTK+ and Gimp.  They are outdated and I
don't know any better FAQs.

There is a FAQ on http://gug.sunsite.dk/faq.php?cat=6 (the Gimp User
Group) but it does not have the same scope as the old ones maintained
by Miles O'Neal.  Besides, I would prefer a simpler site design that
what is currently provided by the GUG (<gripe>please give me a FAQ in
plain text or very simple HTML instead of lots of nested HTML tables
with unreadeable fonts that take forever to render in Netscape on my
old Sun Ultra1</gripe>).

> Also, the build instructions should probably mention this somewhere.
> Possibly even the configure script should print something if it
> discovers it's on a Solaris box, and grepping /etc/system doesn't
> return satisfactory limits.

I don't think that the configure script is the best place to check for
this.  I often build the Gimp on a server that has no display and
still has the default limits on shared memory, because nodody is
supposed to run GTK+ applications on it.  On the other hand, all
client machines have the correct values in /etc/system.  Testing for
shared memory limits in the configure script would not be very useful
in this case.  Also, it would not work for pre-packaged binaries like
the ones distributed on the SunFreeware site.

It is better to check for shared memory limits in the Gimp itself.
This can be done in in plug_in_init_shm() to test the limits on the
client machine every time the Gimp starts.  It could also be done as
part of the user_install phase if we want to avoid repeated warnings
for the users who do not have the rights to edit /etc/system and who
are unlucky enough to have an admin (or a stupid corporate policy) who
does not want to support GTK+ applications.  But then we make the
unsafe assumption that the user will always run the Gimp on the same
machine.  The ideal solution would be to have a dialog box containing
a toggle "do not warn me again about broken Solaris shm stuff" and a
corresponding option in gimprc.  But this may be too much trouble.

Anyway, if we want to test the limit of 6 shared memory segments, we
could use something like this:

#ifdef HAVE_SHM_H
test_shm_limits ()
  int      i;
  gboolean success = TRUE;
  int      shm_id[7];
  guchar  *shm_addr[7];

  for (i = 0; i < 7; i++)
      shm_id[i] = shmget (IPC_PRIVATE, 16384, IPC_CREAT | 0777);
      if (shm_id[i] == -1)
          success = FALSE;
          shm_addr[i] = (guchar *) -1;
      shm_addr[i] = shmat (shm_id[i], 0, 0);
      if (shm_addr[i] == (guchar *) -1)
          success = FALSE;
  if (i >= 7)
    i = 6;
  while (i >= 0)
      if (shm_addr[i] != (guchar *) -1)
        shmdt (shm_addr[i]);
      if (shm_id[i] != -1)
        shmctl (shm_id[i], IPC_RMID, 0);
  return success;

This only tests the limit of 6 shared memory segments per process, and
does not test the other limits such as the maximum segment size or the
total number of segments.  But this should be enough to catch the most
common problem, and display a nice warning with the proposed solution.

By the way, grepping /etc/system is probably not a good idea because
the changes to this file only take effect after the next reboot.  The
only safe way to know the current values is to run the sysdef command.
Unfortunately, its output is not script-friendly and AFAIK there is no
other way to know the current limits if you do not have the
priviledged access to /dev/kmem.


Reply via email to