On Mon, 2 Oct 2000, Austin Donnelly <austin@xxxxxxxx> 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 gboolean 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; break; } shm_addr[i] = shmat (shm_id[i], 0, 0); if (shm_addr[i] == (guchar *) -1) { success = FALSE; break; } } 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); i--; } return success; } #endif 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. -Raphael
