Date: Sun, 31 May 1998 15:50:02 -0400 (EDT) From: Kevin Street <street@iname.com> To: Doug Rabson <dfr@nlsystems.com> Cc: Amancio Hasty <hasty@rah.star-gate.com>, Terry Lambert <tlambert@primenet.com>, mike@smith.net.au, rminnich@Sarnoff.COM, doconnor@gsoft.com.au, hackers@FreeBSD.ORG Subject: Re: Star Office Installation Message-ID: <13681.44921.894518.950536@kstreet.interlog.com> In-Reply-To: <Pine.BSF.3.95q.980531202153.330H-100000@herring.nlsystems.com> References: <87emxa9wa8.fsf@kstreet.interlog.com> <Pine.BSF.3.95q.980531202153.330H-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson writes: >On 31 May 1998, Kevin Street wrote: > >> Amancio Hasty <hasty@rah.star-gate.com> 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. Setting IPC_RMID is the right thing to do, but the code has to be somewhat smart about when to do it, because (from man shmctl): IPC_RMID Removes the segment from the system. The removal will not take effect until all processes having attached the segment have exited; however, once the IPC_RMID operation has taken place, no further processes will be allowed to attach the segment. ... On Linux it's easier because you don't need to wait until all the attaches have been done before setting IPC_RMID. The linux emulation layer must be doing something about this difference in semantics or we'd probably see lots of failed attaches from Linux code. -- Kevin Street street@iName.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13681.44921.894518.950536>