From owner-freebsd-hackers Sun May 31 12:24:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03517 for freebsd-hackers-outgoing; Sun, 31 May 1998 12:24:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03363 for ; Sun, 31 May 1998 12:23:49 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.8/8.8.5) with SMTP id UAA28004; Sun, 31 May 1998 20:23:50 +0100 (BST) Date: Sun, 31 May 1998 20:23:50 +0100 (BST) From: Doug Rabson To: Kevin Street cc: Amancio Hasty , Terry Lambert , mike@smith.net.au, rminnich@Sarnoff.COM, doconnor@gsoft.com.au, hackers@FreeBSD.ORG Subject: Re: Star Office Installation In-Reply-To: <87emxa9wa8.fsf@kstreet.interlog.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 31 May 1998, Kevin Street wrote: > Amancio Hasty writes: > > > Well, I guess on Linux star office misbehaves by deleting its ipc > > shared data segments when it exits. > > > > Most likely whats going is that we are not handling properly the ipc > > calls or possibly something else which is causing Star Office not > > to delete the ipc shared data segments upon exit. > > I don't know about Star Office, but in other code (in KDE > specifically) I've seen constructs like: > > *shm_adr = shmat ( shmid , NULL, 0 ); > > #ifdef linux > shmctl(shmid, IPC_RMID, &buff); > #endif > > which flags the segment for deletion right after the first attach to > it. It works because on Linux you can apparently still do a new > attach to a shared seg even after it's been flagged for deletion. > After the last detach the seg goes away. On other platforms you can't > attach it anymore after you do this, so the code has to be smarter > about when to delete the segment. Perhaps Star Office is making use > of some Linux-only shm semantics too or our emulation doesn't quite > handle this type of usage. When I used to use the XSHM extension, this was the only way to reliably make sure that your system didn't get clogged up with garbage shared memory segments when you are trying to debug an XSHM program. I am sure it used to work - I did this on 386bsd 0.1. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message